1

In many cases, the braces surrounding values to keys in l3keys are omitted when defining keys, even when the keys themselves have n-,c-, or e-type arguments, which normally require braced arguments. Isn't this inconsistent and more confusing than providing the braces?

My questions: (1) Why are the braces sometimes omitted? (2) Which is best-practice for programming in expl3?

My MWE is a just a quick demonstration of defining keys using l3keys without using braced values. In the commented-out code, the keys are defined with braced values.

\documentclass{article}

\ExplSyntaxOn

\keys_define:nn { my }
  {
    string .str_set:c = l__my_tmpa_str , % note the 'c'-type argument
    string .initial:n = initial ,
    string .value_required:n = true ,
    stringadd .code:n = \str_put_right:Nn \l__my_tmpa_str { foo } ,
    stringadd .value_forbidden:n = true ,
    stringadde .code:n = \str_put_right:Ne \l__my_tmpa_str {#1} ,
    stringadde .value_required:n = true
  }
% \keys_define:nn { my }
%   {
%     string .str_set:c = { l__my_tmpa_str } ,
%     string .initial:n = { initial } ,
%     string .value_required:n = { true } ,
%     stringadd .code:n = { \str_put_right:Nn \l__my_tmpa_str { foo } } ,
%     stringadd .value_forbidden:n = { true } , 
%     stringadde .code:n = { \str_put_right:Ne \l__my_tmpa_str {#1} } ,
%     stringadde .value_required:n = { true }
%   }

\ExplSyntaxOff

\begin{document}

\ExplSyntaxOn

\str_use:N \l__my_tmpa_str
\par
\keys_set:nn { my }
  {
    string = blah
  }
\str_use:N \l__my_tmpa_str
\par
\keys_set:nn { my }
  {
    stringadd
  }
\str_use:N \l__my_tmpa_str
\par
\tl_set:Nn \l_tmpa_tl { blah!!! }
\keys_set:nn { my }
  {
    stringadde = \l_tmpa_tl
  }
\str_use:N \l__my_tmpa_str
\par
\keys_set:nn { my } { stringadd }
\str_use:N \l__my_tmpa_str
\ExplSyntaxOff

\end{document}
5
  • 1
    I'd say best practice would be following interface3.pdf which does use braces for arguments of these types with the exception of boolean values (true|false) which are standardly non-standard ;). E.g. ⟨key ⟩ .initial:n = {⟨value ⟩} (page 241). Note that 'required' is a bit optimistic here. expl3 syntax is typically unenforced, so the fact that it works doesn't make the case of setting or defining keys any different from other cases. Any differences emerge from the underlying TeX as collateral damage.
    – cfr
    Commented Jan 13 at 1:58
  • In a lot of the example code in l3keys, the braces are omitted. Commented Jan 13 at 2:36
  • 2
    you want to be able to omit braces around the value at the top level key use fontsize=12pt not \fontsize={12pt} so pretty much all kv systems take the value as everything from = to the next , or end, possibly with space stripping, as the value, Then allow stipping of one level of braces to hide any = or , that need hiding. l3keys uses kv syntax also for defining the keys so you see the same here. If your initial value was a,b not initial then the braces would be needed. As it isn't, they are optional. Commented Jan 13 at 13:32
  • 1
    @DavidCarlisle there is one strange package that does no brace stripping at all by design... And there are some which strip more than one set of braces sometimes. Pretty buggy :P
    – Skillmon
    Commented Jan 13 at 13:54
  • 1
    @Skillmon details... Commented Jan 13 at 13:55

1 Answer 1

4

There is a documentation in interface3 that defines what is valid input inside key=value-lists (see subsection 27.10). I don't want to repeat everything here, but it boils down to the following:

Braces are optional and don't make a difference unless (outside any nested braces):

  • your value includes commas
  • your value includes at least one equals sign
  • your value has at least one space on either end

If none of the above are true, the braces are completely optional (and indeed you get better performance if they are omitted, because TeX has to shift fewer tokens around).

So, what is "best practice": Whatever you find easier to be read and maintained -- and if you're after minute speed improvements omitting every unnecessary set of braces. But as soon as you forward user input you don't know whether that will include spaces/commas/equals signs, so in that case you should absolutely use braces.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .