lib/types: make pattern of strMatching accessible

[hsjobeki]

Makes pattern of strMatching accessible in the option tree.

Thus this allows to generate for example json-schema validation
https://json-schema.org/understanding-json-schema/reference/regular_expressions

Context: I am building a Frontend that is partially derived from those options. Exposing the pattern is very helpfull in that case.
Otherwise my users get evalModules eval stacktraces. Which is after the field was submitted / sent to the server.
If i knew the pattern upfront then i can display feedback as the user types.

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.

[roberth]

I'm pretty sure this wasn't the original intent of the functor attribute.
We'll need to either encourage this or come up with an alternative.
@infinisil wdyt?

[hsjobeki]

@infinisil. I thought that it could make sense to move away from using wrapped in defaultFunctor entirely, for all types.

Instead using only payload with payload.wrapped beeing the new convention for wrapped.
I hoped this could reduce technical complexity as shown:

# Example for 'types.attrsOf'
functor = (defaultFunctor name) // {
       # These could be defaults for composed types.
        payload.wrapped = elemType;
        type = payload: attrsOf payload.wrapped;
        binOp = lhs: rhs: { 
           wrapped = lhs.wrapped.typeMerge rhs.wrapped.functor; 
           # Place for other payload merging, no need to decide between .wrapped and .payload. (see attrsWith, which uses both)
         };
      };
      

Once all types use payload exclusively. This reduces complexity in the typeMerging functions.
Because payload can include all of wrapped functionallity as well, and is extensible for type specific additional attributes.
For example:

• attrsWith has placeholder
• strMatching has pattern
• separatedString has sep
• attrTag has tags
  ...

  defaultTypeMerge = f: f':
   let
       payload = f.binOp f.payload f'.payload;
   in
   # cannot merge different types
   if f.name != f'.name
      then null
   # simple types
   else if  (f.payload == null && f'.payload == null)
      then f.type
   # all other types
   else if (f.payload != null && f'.payload != null)
      then f.type payload
   else null;

[infinisil]

After #363565, we could make functor.payload stable (along with functor.{binOp,type}, and kind of functor.name), but that's a bit of a separate discussion.

While this doesn't fix a problem related to Nixpkgs (seemingly nobody has ever needed type merging for strMatching!), this doesn't break anything and unblocks @hsjobeki with getting access to the pattern for a UI, so I think this is fine to merge :)

[nixos-discourse]

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

https://discourse.nixos.org/t/use-cases-of-option-type-internals/57317/1