l3pdf feature request: providing variants for pdf-object-related functions that expand their object name argument about latex3

[FrankMittelbach]

Something to contemplate, for sure (and maybe decide against it), but "n" doesn't mean no expansion, it just mean no expansion before calling the base form of the command and the base form then may do all kind of expansions on its own (e.g., \int_set:Nn etc). hooks, sockets and I guess also properties are of the kind where automatic expansion is natural (and happens in fact down the road where the argument is used to make up internal csnames which is typical for complex "named" types. As I said the "prop" type is different, there whatever you feed in becomes a key unchanged and that "kind of" makes sense, but that key is not a complex type and not intended for anything other than retrival from the prop.

It guess it needs looking at case by case, but complex, named types have the tendency that the name should be a simple ascii string with a clear set of allowed characters and as such expansion towards that at some point is the norm rather than the exception. An inthat case make the "n" expand directly in the base command saves a lot of hassle imho. But I guess something to think about and discuss further.

[josephwright]

Just e-type variants to add? No problem ...

[agrahn]

To be honest, I think it would be OK if such arguments generally do e-type expansion because right now anything other than string would be invalid syntax at the moment.

I would prefer this behaviour.

[u-fischer]

yes, I agree, some e-variants would be useful.

[FrankMittelbach]

To be honest, I think it would be OK if such arguments generally do e-type expansion because right now anything other than string would be invalid syntax at the moment, but I'm also OK with just adding the extra decorations.

[josephwright]

@FrankMittelbach Not sure I follow: the name at the TeX end could be \foo and that would be fine, surely? It's just a label. But I've no real issue in changing behaviour if we feel that's useful on balance.

[josephwright]

OK, I'll make it so: checkin later today.

[FrankMittelbach]

@FrankMittelbach Not sure I follow: the name at the TeX end could be \foo and that would be fine, surely? It's just a label. But I've no real issue in changing behaviour if we feel that's useful on balance.

in my opinion that is (barely) okay for the keys on the prop type but the object names on other types are very regularly used in code to build substructures and it is basically a mess if you end up with \foo in the middle of a csname that looks like a command when displayed but is effectively a string. In my opinion such names such be fairly well regulated ... and I'm very much for duck typing in that respect. It is a bit like "can an environment contain | < > % \ what have you in its name" ... technically it can (for some of them) but the documented syntax (for good reasons) is much more restrictive, same with hooks and hook labels etc. And I think pdf objects fall into the same category. Down the road it will simplify usage a lot. (my 2 cents after midnight)

[u-fischer]

I quite agree that if there is a command in the name I want to expand that, but would it be in line with similar cases if we change the behaviour here and expand even if the argument is n? E.g. hook names, socket names, property names?