Will Robertson wrote: > As far as I'm concerned, it's now or never for the expl3 code (some > might even say it's too late). I think we're at a stage where we can > state: we've iterated some ideas and this seems the best we can achieve; > if you use it now we will support backwards compatibility to the best of > our ability. Agree entirely. I'd imagine we may find that one or two functions have to be re-worked at some point, but as a percentage of the whole this should be very small. I'm not sure stability in the LaTeX2e sense (nothing changes) is desirable in any case: sometimes you need to "bite the bullet". > P.S. Joseph, I can't help noticing your use of \cs_new_nopar:Nn. I know > that without an argument this usage is (in TeX terms) more "correct". > But, unless I was drastically mistaken, the assumption we made when > naming these functions was that it didn't really matter to have some > spurious \long's and we really wanted people to use \cs_new:Nn in all > cases except when they *specifically* wanted to restrict \par. (Since > the \long case is more general and more frequent. Restricting \par in > the input is better achieved when defining the user commands than the > underlying commands beneath them.) Unfortunately, there are lots of > cases in source3 where this convention is not followed, but only because > the translation was performed mechanically. What do you think about the > whole thing? My take (in what I've done in siunitx) is as follows. Where there is any chance that \par might pop up (most functions), I've used \cs_new:Nn. I've only used \cs_new_nopar:Nn in two types of case: - Functions with no arguments. As there are no arguments, the question of \par tokens never arises. So it makes no difference whether I use \cs_new:Nn or \cs_new_nopar:Nn. As I've said before, I feel it is better to use more restricted functions if possible. - Cases where I'm coding an aux function with known input. In the example I gave: \cs_new_nopar:Nn \siunitx_load_check: { \clist_map_function:nN { SIunits, sistyle, siunits, SIstyle } \siunitx_load_check_aux:n } \cs_new_nopar:Nn \siunitx_load_check_aux:n { \group_begin: \@ifpackageloaded {#1} { \msg_error:nnx { siunitx } { incompatible-package } {#1} } {} \group_end: } \siunitx_load_check_aux:n is only ever used to process an item from the in-line clist in \siunitx_load_check:. They can never contain \par, so again I can use the "most restricted" function. So there should be no cases where user input is restricted by my choices: I'm using xparse to do that. (Having said that, I should probably check through the code I've to make sure I've stuck to that scheme carefully.) -- Joseph Wright