On 14/07/2015 09:13, Ulrike Fischer wrote:
>> The .default:n is different: an empty default is not the same as no
>> default at all (as a default means effectively a value is always given).
> 
> In many cases it is. E.g. I could see not difference with the
> .code:n or .tl_set:N. And even choice keys works without a default:
> 
> \documentclass{article}
> \usepackage{expl3}
> \begin{document}
> \ExplSyntaxOn
> \keys_define:nn {test}
> { 
> testa .code:n     = {the~argument~is #1!},
> testb .tl_set:N   = \l_test_tl,
> testc .choice:,
> testc /   .code:n={xxx},
> }
> 
> \keys_set:nn {test} {testa,testb,testc}
> 
> \tl_if_empty:NTF\l_test_tl{~empty}{not empty}
> 
> \ExplSyntaxOff
> 
> \end{document} 
> 
> But  .default:n={}  wouldn't work with bool. 

I'll take a look over the code: I was actually thinking of the
interaction between a default and a value being required, but it doesn't
seem to work the way I thought it should!

>>> -  the action can be reset by setting a new action.
>>
>> True, and again I will clarify docs.
>>
>>> Missing is ".value_not_required:" and ".value_not_forbidden:". 
>>
>> I wonder if best would be to deprecate current .value_required: and
>> .value_forbidden: and go to .value_required:n and .value_forbidden:n
>> taking boolean values? 
> 
> Imho it would be more logical to use booleans. But deprecating
> things is naturally always difficult ...

We have a clear mechanism to make changes: we know that expl3 is still
developing and there are areas that simply haven't been tested a lot.
I'll go with the change here.

>>> Missing is an explicit ".unknown:", which would e.g. allow to remove
>>> choices from a key. An accompayning ".known:" which reactivates the
>>> key would be interesting too. (I don't know if the code allows
>>> this). 
>  
>> As previously noted, making a key unknown removes the code behind it
>> entirely. Unless there is a compelling use case I'm minded to leave this.
> 
> If there is an .undefine: action it should be possible to remove a
> choice with testkey / choicea .undefine:, so an .unknown: is not
> really needed. 
> 
>> Based on the fact that as far as possible the key property names follow
>> other expl3 things (see .tl_set:N, etc.) I will probably go with
>> .undefine:, although .unknown: would also fit nicely with the way keys
>> are described.
> 
> For me ".unknown:"  is a property, ".undefine:" an action. If code
> is destroyed I would use the second. 

That also occurred to me: .undefine: it is.

> Side remark: Did you saw this question on tex.SX:
> http://tex.stackexchange.com/questions/254878/mactex-2015-running-much-slower-than-mactex-2014/254946#254946
> 
> I wonder what the expl3 code of mhchem is doing there. It looks like
> very long recursions ...

A quick look suggests the author has decided to use the regex engine for
some parsing. I can see the attraction in a complex situation like
mhchem but at the same time no-one is going to pretend that it's
designed for speed. Probably I'd stick in a similar situation with using
lower-level constructs. (I have something similar in siunitx, where it's
clear that all of the number parsing needs to be carefully examined to
get the best speed out of TeX, expl3 or not.)
--
Joseph Wright