@Arg(required = false) vs. @Nullable

[sockeqwe]

So how should we deal with optional values in 4.0.

Should we remove @Arg(required = true or false ) in favor of @Nullable and @NonNull annotation from support library?

How to integrate Kotlin null safety ?.

[sockeqwe]

Moved into backlog as this is not easy to implement (especially the kotlin part as it may requires a annotation processor tailored on kotlin ). For now (in 4.0) we stick with @Arg(required = ...) for optional values

[anggrayudi]

If that so, can we make @OptionalArg or @RequiredArg instead?

[p-fischer]

I just discovered this library and think it's a great idea and good work! :)

Regarding your question: I'm just asking myself do we need to differentiate between

• the value is provided as null
• the value is not provided

While there might be a semantic difference I see no reason why this is required in practice. If so only one of the annotations would be required where I would prefer the canonical ones @Nullable and @NonNull.

I don't know if this helps, but when I read a non-null / required argument in a fragment I usually use this pattern:

field = arguments?.getParcelable(ARGS_NAME) 
            ?: throw IllegalArgumentException("${javaClass.simpleName} requires argument $ARGS_NAME.")

Hence, following the philosophy fail fast on programming errors. I would love to see something similar in your library.

Users of your library are prevented of forgetting required arguments as long as they use the generated builder. Once the builder is not used required arguments might still be missing.