RFC42-style options that default to unset, to have no attribute in config despite option

[roberth]

When defining an option in an RFC42-style free-form settings module, say settings.foo, the module system always creates a config.settings.foo value containing the default value.

Some configuration formats require that config definitions are omitted in order to get the default behavior. Filtering those out of the config is unpleasant at least and as far as I know we don't have a standard solution for it.

We could add a mkOption argument that has the effect of producing no default value and no config attribute when no definitions are present for the option.

This will allow us to simplify modules that need to elide unset options and it lowers the threshold for defining options within a settings module, improving documentation and merge semantics.

Notify maintainers

@infinisil

Additional context

This idea has come up in #112494 as well, but I'm not convinced that it isn't feasible.

[adrian-gierakowski]

This would be useful for me, how could I contribute to making this happen?

[roberth]

I don't feel like this should be part of submodule anymore, because it already bears so much complexity. Also RFC 42 settings are a use case where we're not doing any programming, but rather just modeling some data, so all the fixed point and introspection business is unnecessary.
Something simpler like types.record in #257511 could do the job instead, and it'd also be much easier and less risky to implement this feature onto that.
(Ignore types.fix; it's not capable enough to recover full submodule functionality, but we don't need that, and the module that contains the settings can be responsible for tying the knot. We don't need that to happen inside the settings itself; as said, we're not doing module-like programming in there.)
(A very concrete risk is that optionality implies having a filterAttrs somewhere, which adds strictness, as the attrNames of that requires evaluating all those declarations first, which IIRC currently isn't the case. Any new strictness will lead to unexpected errors including infinite recursions.)
I'm not sure exactly where to start with improving types.record, but I'll leave some comments. (Or maybe it's best to start from scratch?)

cc @infinisil