lib.types.defaultTypeMerge: refactor functor.{payload,wrapped} merging

[hsjobeki]

Refactors defaultTypeMerge

• all possible combinations are now obviously covered.
• types with functors that declare both payload and wrapped at the same time are now an explicit error.
  This shouldn't have worked before and will now be an explicit error.
  If anyone relies on having both they should decide. While I recommend using payload.elemType together with binOp.
  See the existing types that use functor.payload for examples.

What also changed:

• payload is merged first if it exists
• wrapped is merged lastly if it exists

This change is related to #344216 because it is a type that needed both wrapped and payload.

In the long term .wrapped should be removed because all of its purpose can also be done via payload.elemType this removes one order of complexity from the merge logic matrix

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/)
• 24.11 Release Notes (or backporting 23.11 and 24.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.

[infinisil]

The need to flip the order isn't obvious to me, can you explain that?

[hsjobeki]

The need to flip the order isn't obvious to me, can you explain that?

I have two arguments mainly:

1. In this example lib.types: attrsWith named placeholder #344216

   We have a type that has both wrapped and payload but the merge function returns the merged wrapped early without merging the payload. The other way around would be better.

2. In the next couple of PRs want to refactor the merge behavior for composed types such that they use payload exclusively.
   i.e. payload.elemType instead of wrapped until we can remove this codepath completely. I have some ideas what we need to change for that. Giving wrapped less precedence is also an necessary preparation before one could do that.

[infinisil]

As a reminder, me and @hsjobeki just had a meeting where we looked at this and improved it to a point where I think it's ready to merge. Still needs to be pushed and the PR title/description updated though :)

[hsjobeki]

@infinisil Just pushed all the updates we made.
I am wondering: Since we now decided that wrapped + payload is an error. This means attrsWith and the resulting types attrsOf and layzAttrsOf must use payload exlucsively. This could potentially break downstream code that relies on functor.wrapped

So maybe we should add a warning instead of a hard failure?

[infinisil]

This would be a potential problem with the attrsWith PR, it doesn't apply here, so we're good :)

(written next to @hsjobeki in Zürich #ZurichZHF :))

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/breaking-changes-announcement-for-unstable/17574/72