Hi Robert!
I'm not a member of the lombok team, but I implemented the @SuperBuilder
feature. This feature is already very complicated in two ways: The
generated code is quite long even for small classes and loaded with
generics, and the lombok handler classes are complicated, too.
So from my point of view, every addition that further increases the
complexity should be very-well justified, i.e. it must help a
significant part of lombok users, and cannot easily be replaced by
different means.
Your proposal looks reasonable. However, I doubt it will cross the bar
for both criteria described above:
1. The use-case you describe seems rather rare. Why do you want to
convert an existing ParentBuilder to a ChildBuilder? Could you elaborate
further on possible applications for such a feature?
2. Even if there are use-cases for this, I believe there are easy
workarounds. For instance, you could invert the responsibility of
creating the builder, like this:
ChildBuilder<?,?> builder = Child.builder();
methodThatFillsValuesIntoParentBuilderInstance(builder);
Child child = builder.build();
Even if you really need the other method to create the builder, you
could pass the desired target (builder) class as parameter to that
method, and also use that as return type.
Jan