This looks alright. I really like the "stack" approach of having the innermost name first. Perhaps this could be reflected in the name, like nameStack? After all the innermost thing doesn't have multiple names and "stack" gives a good clue.

I'm also wondering about lists. I'm not actually a big fan of those, but perhaps it's useful to include list indices in it? Not sure what the name should be in that case. pathStack? I guess it can be added later with a name like that if needed.

@roberth I like the suggestion of calling it nameStack instead, applied that.

I think using a list like that is fine for now.

@roberth You think this is looking good now? If there aren't any complaints I'll merge it

I marked this as stale due to inactivity. → More info

@roberth But what would the name be? We can't name things without names! There's no inherent naming for the level of submodule recursion

@roberth But what would the name be? We can't name things without names! There's no inherent naming for the level of submodule recursion

The module author can choose their own names.

@roberth The problem is that there's no naming of these values defined. To do this you'd have to e.g. extend the definition of attrsOf to support something like

attrsOf {
  metaName = "myName";
  elemType = ...;
}

This would then allow you to access myName with

{ names, ... }: {
  result = names.myName;
}

I'm also not convinced that this specific PR is a good idea, but I'm also not sure how else it could be done nicer.

{ names, ... }: {
  result = names.myName;
}

This is an improvement, but I don't think it's necessary.
We can use the lexical scope:

{ name, ... }:
let virtualHostName = name;
in {
  options.locations = mkOption {
    type = submodule ({ name }:
      let locationName = name;
      in {
        config.baseUrl = lib.mkDefault "${virtualHostName}/${locationName}";
      });
  };
}

Granted, this does not work for directly nested attrsOf (attrsOf submodule) but that's a code smell anyway, because the relation between these layers is unclear and you can't really extend the outer attrset with other options. (webserver.hosts.<name>.locations.<name>.xyz vs webserver.hosts.<name>.<name>.xyz)

Hm yeah fair enough, let's not do this then.

Granted, this does not work for directly nested attrsOf (attrsOf submodule) but that's a code smell anyway

Since we have attrTag now, the same problem applies there, but attrsOf (attrTag ts) is not a code smell.

I do think we should use the lexical scope for this, so that we don't need to invent an ad hoc naming system for these "name" variables.
Concretely this means something like attrsWith { itemType = name: submodule { options.foo = mkOption { default = name; }; }; }

• See Module system types.attrTag shadows name argument for inner submodules #351888