For reference, I'm adding the concerns raised by @nbp here:

This patch adds ambiguous behaviour in the way options are processed. One simple value can change the way all other values are interpreted without any warning.

foo = {
  value = 42;
};

from one module can make the change the semantic of value if it is defined in both submodules.

If we are going to do so, I think the merge function should ensure that the set of options are completely disjoint.

In the mean time, I do not think this is a good idea, and suggest we should not accept this patch.
Also, why did this patch went into master without requesting a review?

@nbp: And here again, I still don't understand what you mean by "changing the semantics", for example if I use something like this:

{ lib, ... }:

{
  options = {
    foo = lib.mkOption {
      type = with lib.types; either str int;
      description = "foo";
    };
  };

  imports = lib.singleton { foo = 666; };

  config = {
    foo = "bar";
  };
}

I get an error as expected:

error: The option `foo' has conflicting definitions for type either, in `...' and `...'.

What I meant by "changing the semantics" is best explained with the following example:

If you have an option definition that can be interpreted with both side of the "either", then you will consider the first operand of either to merge the values.

The problem appears, as soon as you have a second option definition, but which only validates with the second type. In such case, the first option definition would be interpreted with the second type instead of the first one, as it used to be without the second option definition.

I think it would be wise to ensure that either is exclusive. I understand the need for having a simple type, as a way to make a simple/refined interface. (even if I would be tempted to have the simple type definition be mapped to one of the submodule options instead of using either)

Still I think the patch which got landed lack the disjoint feature, which I do not want to have to explain nor support in the future.

@aszlig I wonder, would it make more sense to do it as an option set attribute which is interpreted to forward simple value (no attribute set) as the value of an option which is located below, such as:

options = {
  _defaultOption = "display";
  display = mkOption { … };
  primary = mkOption { … };
  extraConfig = mkOption { … };
};

What do you think?

This way we would have a similar feature without the burden of creating submodules, when we just want a shortcut notation.

One case where this would make total sense, would be for url, where we might want to decompose them into multiple options:

let
  parseUrl = url: {
    protocol = …;
    domain = …;
    port = …;
    path = …;
  };

in

{
  options.services.foobar = {
    listen = {
      _default = "url";
      protocol = mkOption { … };
      domain = mkOption { … };
      port = mkOption { … };
      path = mkOption { … };
      url = mkOption { … };
    };
  };
  config = {
    listen = mkDefault (parseUrl config.url);
    firewall.openTcpPort.port = config.listen.port;
  };
}

Hm, I think this makes more sense and we should also ensure that either will bail out with an error if someone tries to use it in conjunction with a submodule, because right now either foo submodule doesn't typecheck the submodule at all and pretty much functions like either foo attrs or either foo function.

@aszlig

Hm, I think this makes more sense and we should also ensure that either will bail out with an error if someone tries to use it in conjunction with a submodule

I agree, if we have the possibility of failing sooner we should consider it.

What's the consensus now, so I can make the necessary changes to my PR? #13916

@CMCDragonkai I think the above discussion settled on the _default attribute, as a short-cut to an option definition which is declared in the same set. I am not sure if @aszlig wanted to work on it or not.

@nbp: I haven't started to work on it, yet. Will see whether I get to it next week, but I can't promise that it'll work out.

Any news on this?

@CMCDragonkai: Yep, we now have types.coercedTo, which should solve this. Implementing this and pushing it to #15353.

@aszlig Cool, so how do we use it?

I'm seeing a problem where I'm doing something like

types.either (types.submodule submodule1) (types.submodule submodule2);

where the 2 submodules have different options inside (for example the first one has option a and the second one option b inside), and I get the error:

error: The option myoption.b defined in ... does not exist.

It seems to bail out immediately checking only the left side of the either, instead of allowing that either side's types are allowed.

Is it possible that this issue was not fully solved?

@nh2 This issue is fully solved, but this is a deliberate limitation of the either type.

You cannot use either with types which have the same representation. Checking for submodules it is the same as matching one attribute set. There is no (cheap) way to do it here.

Moreover, this would be difficult to document, and thus confusing for the users.

If you want to do so, create 2 options, where each has a submodule type.