(continues from #nix-lang:nixos.org )
Matt Sturgeon:

you're asking a module system question, so NixOS Module System is more suitable 🙂

Ah! I didn't know about that channel. Thanks for pointing me here.

Either by shadowing check with submodule ... // { check = ...; } or extending it using lib.types.addCheck

Mh, I'd need to check how that works before I can fully understand that. Any reading material you suggest? Maybe there's a guide about internals of the modules type system.

Note that these may not work well with v2 check&merge (where checking is partly handled by the merge.v2 function).

No idea what v2 check&merge is, is that opt-in? Is something that's going in soon?

how should an empty module be handled?

None should match, type is a single-element enum with no default, so all of them should fail.

Right now I manually made a "union type" (where everything that a single type would allow, is allowed), and it has already bitten me.

bake.monorail: Thanks for asking this here. I have some similar ideas. This is currently a limitation of the type system.

We don't have explicit union discriminators.

Because we currently use check as union discriminator.
The check of a submodule is isAttrs x || isFunction x || path.check x so the first submodule type gets picked always.

There are some action points that i'd like to accomplish and one needs to figure out the order of them:

• Make oneOf the basetype of either. Currently inverted logic.
• Allow user defined explicit discriminators. Currently: implicitly reusing check def where we should do discriminator merged.value

bake.monorail: Thanks for asking this here. I have some similar ideas. This is currently a limitation of the type system.

We don't have explicit union discriminators.

Because we currently use check as union discriminator.
The check of a submodule is isAttrs x || isFunction x || path.check x so the first submodule type gets picked always.

There are some action points that i'd like to accomplish and one needs to figure out the order of them:

• Make oneOf the basetype of either. Currently inverted logic.
• Allow user defined explicit discriminators. Currently: implicitly reusing check def where we should do something along !merged.headError && discriminator merged.value

bake.monorail: Thanks for asking this here. I have some similar ideas. This is currently a limitation of the type system.

We don't have explicit union discriminators.

Because we currently use check as union discriminator.
The check of a submodule is isAttrs x || isFunction x || path.check x so the first submodule type gets picked always.

There are some action points that i'd like to accomplish and one needs to figure out the order of them:

• Document the limitations of the current system
• Make oneOf the basetype of either. Currently inverted logic.
• Allow user defined explicit discriminators. Currently: implicitly reusing check def where we should do something along !merged.headError && discriminator merged.value

I'd need to spend some time on the implementation of the modules system to be of some help.
I've no idea what the check function is, for instance.

I don't want to derail the discussion, but I'll just leave here my complaint that nix is lacking a type system and it's being reimplemented at run-time.
For instance, for "public API" functions I made up the following "type safe" function using the module system:

let
  typeSafeFunction =
    { options, implementation }:
    # Return a function that accepts some arguments
    arguments:
    # and invokes the implementation
    implementation
      # Passing as arguments the result of evaluating the module
      (pkgs.lib.evalModules {
        modules = [
          {
            inherit options;
            config = arguments;
          }
        ];
      }).config;
xxx = typeSafeFunction {
  options = { arg1 = mkOption { ...}; };
  implementation = { arg1 }: arg1 +1;
};
in
xxx { arg1 = 3; }

Which is a bit absurd.

It seems to me that the general feeling in the community is that nix won't get a type system any time soon. Maybe we need something like TypeScript, a TypeNix transpiler. I'm sure there already are some efforts like that.