Support strict staged builders on collections/optionals

[raiju]

What happened?

Omitting optional fields reduces boilerplate, but also makes it easier to accidentally forget to plumb through a new field across different parts of an application.

What did you want to happen?

Either a flag or a separate builder which generates stages for required & optional fields (& forces passing in explicitly empty collections/optionals)

[carterkozak]

Every change would result in an Abi break for consumers. It could make sense with conjure-local, but I think it would be too dangerous everywhere else.

…

-ck

On Feb 24, 2022, at 18:26, Sander Kromwijk ***@***.***> wrote:  What happened? Omitting optional fields reduces boilerplate, but also makes it easier to accidentally forget to plumb through a new field across different parts of an application. What did you want to happen? Either a flag or a separate builder which generates stages for required & optional fields (& forces passing in explicitly empty collections/optionals) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[adamliesko]

Every change would result in an Abi break for consumers.

I don't think either of the 2 proposed "approaches" (separate builder or a flag) would be breaking for consumers.

We have also had a few cases in our product where this would be useful, even though I am not sure it would deliver the value as promised, meaning if it would actually get used enough organically.

[carterkozak]

The generator flag would break any consumer with uses the generated objects.
I don't want to support multiple types of builder per object as it provides more optionality than I'm comfortable with, and doesn't make it clear to devs on new projects which they should use.

[carterkozak]

There's a potential solution where we use one implementation for compilation, and another (more lenient) at runtime. Requires some interesting build/compilation hacking to get the best of both worlds....

[raiju]

@carterkozak Sorry for the gap in comms, need to fix my notifications 😓

Do we have other places where we do this already, or would this be a first?

On the multiple types of builder, could this be solved by adding a linter? It feels like it should be possible to e.g. forbid the non-strict builder for a given package (e.g. by forbidding all uses of builders w/ a @NonStrictBuilder annotation; I admit I haven't written any errorprone linters/rules though, so not sure that's the right way to approach it)

The main issue here for us is actually project-internal (not so much our client's usage)