Hello all, The ongoing template discussion has prompted me to think again about some aspects of l3keys. It's pretty clear to me that the aims in l3keys are rather different from those in template. l3keys is really about creating keys for the programmer, so it can take a very different approach to template. Several things have come up in the discussion, and I'd like to see how other people feel about the following before doing anything: - I added .initial:n and .initial:V mainly with template in mind. In l3keys, initial values can be set using \keys_set:nn, and overall I feel this is probably clearer (separate key definition from key setting). I'd therefore like to drop .initial:n/V - There is .function:N which again was more about template than l3keys. I'm not sure the property is actually very clear (it does \cs_set:Nn <function> { <key-value }), so again I'd like to remove it. - There are currently a .code:n and a .code:Nn property, where the former only takes one argument and the later takes N. To be honest, I think it might be better to only have .code:n so that if further splitting of a value is needed it is done elsewhere, and not by l3keys. - Related to the .code:Nn point, .generate_choices:nn also splits the value part of a key-value argument in two. I'm no longer sure this is a good thing, so perhaps .choice_code:n = <code>, .generate_choices:n = <choices> would be better. - Not everyone likes the .set:N idea of detecting the variable type and scope from the variable name, rather than having .tl_set:N, .int_gset:N, etc. As we are talking about a programmer function, it's not unreasonable to read the variable information from the name. It's easy to go back to the previous method if that is the consensus. I'd like to get this sorted out soon (i.e. in the next week) as I am using l3keys for siunitx v2 and as Manuel has indicated he is also looking at using l3keys for real work. -- Joseph Wright