> It's a bit more complicated than that :-) It usually is! > If you look at the code, any case where someone sets up a 'choice of choices' > will fail. That's not good, and so before any worries about booleans > specifically I'll fix this more general issue. My feeling is that trying to set up a > 'choice of choices' key is an error in the definition rather than at point of use, > so I'm minded to trap such cases and issue a error message. Does that sound > reasonable? For example, what is something like > > key-1 .choice: , > key-1 / choice-a .choice: , > key-1 / choice-a / value-1 .code = ... > > actually going to achieve? Yes, I'd noticed that it will fail (I actually mentioned it in passing in the tex.stackexchange discussion), but it didn't worry me so much precisely because I couldn't think of any reason why one would want to set up a case like that. Of course, it's definitely better if attempts to do so raised an error instead of getting stuck in a loop! > One the specifics of boolean keys, I can see the point here about > set_true/set_false as they match 'normal' variable setting. On the other > hand, the original design here was to recognise that a boolean key is > somewhat 'special': it is a choice from a limited range of values. > Moreover, my thinking was that enforcing "true"/"false" as the values > avoided the possible need for people to allow for "on"/"off" or "yes"/"no" > (I've worried about this in the past). It was also meant to indicate that a > boolean key should be one that 'reads' as > > <thing> = (true|false) > > rather than > > <thing> = (foo|bar) > > as that seems less useful to the end user (if the options are more complex > than true/false then some other description is needed at the documentation > level anyway). I see your point, but I can also imagine cases where at the user end it might feel more natural to have something like \mymoduledoclevelsetup{ turnfooingon } \mymodulecoclevelsetup{ turnfooingoff } instead of \mymoduledoclevelsetup{ fooing = true } \mymoduledoclevelsetup{ fooing = false } I guess the decision here is really between nudging package authors towards uniformity and trusting them to develop a syntax that's best for their target users on their own (it's not exactly imposing uniformity, because a package writer stubborn enough could always type the few extra characters to get " turnfooingon .code:n = { \bool_set_true:N \l_mymodule_fooing_bool } "). I tend to be a fan of uniformity myself, but I wouldn't go as far as to claim I have a worked out ideological position on it. :) Best, Jura