lib.types: init mergeTypes

[hsjobeki]

Expose a utility for merging types together manually

Related: #363565

Sometimes downstream projects want to extend an enum and it is quite complicated to understand which attributes of a type are meant to be internal.

catppuccin/nix#400

This PR help to reduce downstream reliance on type attributes by adding this function as abstraction.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[hsjobeki]

@infinisil What do you think about this function? It abstracts the need to use attributes of a type which i think is good. Because it decouples them and allows changes without breaking.

[infinisil]

I think I like it!

[infinisil]

This seems like an implementation detail

[roberth]

Suggested change

	Uses the merge function of the first type, to merge it with the second type.
	Uses the type merge function of the first type, to merge it with the second type.

This is relevant for solving the "expression problem". Interactions between extensions don't have a natural home. This says that interactions are the responsibility of the first type. Concretely: if the types can be merged, you can only fix it if you control the first.
If you have to deal with a partially applied mergeTypes, you are subject to the provided type's merging support, with no way to extend its merging behavior.
If you control the first argument, you can add as much merge support as you like.

[hsjobeki]

I had similar thoughts as roberth. If you want to change some of the merge behavior its important to know that merging is not commutative. In most cases it might be, but thats only true when both types are the same anyways.

[infinisil]

I'm a bit worried that this API isn't very future proof, because null doesn't allow for better error messages. How about we change it to return a string instead, for now just always "Cannot merge types"

[hsjobeki]

How about a set { error = "..."; } representing the empty type? Since a "type" is also an attribute set internally this means it is somewhat homomorphic. You can check for the success by checking result ? error .

We could extend that set in the future to contain more error related information

[hsjobeki]

I made this an attribute set { error = ... ; } for now.
I think this is the best compromise that is extensible in the future.

Error case alternatives:

• string: Some Error: Not extensible in the future. (Cannot hold other attributes)
• null: null: Leaks an implementation detail. Cannot hold any helpful information about the actual problem.
• Throw "error": Downstream projects cannot handle error cases. (downstream wrapping with TryEval not a good idea either, since the error is not made accessible)