Will Robertson wrote:
>> \DeclareDocumentCommand \foo { o[default] m } % now has a default!
> 
> Is the syntax to use square brackets or braces? (I thought the latter,
> which is why I ask. As always, I prefer braces; what if the default is
> to contain brackets?)

Oops, yes, Will is correct.  The idea here was "optional braced
argument" (partly for the reasoning that, as Lars says, [ ... ] is
user-level mark up).

> Lars mentions that he thinks the optional argument is unnecessary; I'm
> not fussed either way, but I like the simplicity of being able to write
> {o m} and having a standard boolean test to check whether it's present
> or not.

That was my thinking: it also means that the \IfNoValue test knows what
to look for!

>> The current xparse implementation lets you create your own specifier
>> letters. This is probably very risky:  what if two packages use the same
>> letter?  I'd drop this idea.
> 
> One comment I have here is that in the future I don't see many people
> defining weird combinations of arguments due to the prevalence of
> keyval-style argument processing instead. I'd even think about dropping
> coordinate-style parenthesis input like "(x,y)" based on this. (Which
> can be emulated easily enough with "d()" and a clist mapping in the input.)

The main reason for keeping a letter for (x,y) is that it can be a
mandatory argument in LaTeX2e, so needs special handling.

> On the other hand, I've been keen on the idea of an optional braced
> argument. If it's an all-or-nothing decision about including marginised
> option types, then I'd rather keep 'c' and also add 'n' (or whatever) to
> represent that. 

Okay, I'm sure we can work that in. "n" seems as good a letter as any.

>> Will has suggested that we should insist optional arguments follow
>> directly on, with no spaces, to mean that:
>>
>> \foo*{arg}  % #1 = TRUE, #2 = "arg"
>> and
>>
>> \foo   *{arg} % #1 = FALSE, #2 = "*"
>>
>> are treated differently. The idea here is that it makes LaTeX syntax
>> more "regular", useful for translation to other formats.  I think he's
>> right, but wonder how others see it.  The current xparse allows both
>> space-skipping and non-space-skipping tests.  I'd certainly say we
>> should go with only one: either spaces are allowed or they are not.
> 
> 
> Re-reading your approach in xparse-alt, I believe what is currently
> implemented there is the best approach. It applies sensible defaults and
> allows overrides; to whit:
> 
> {m o}    does not skip spaces
> {m o m}  does skip spaces
> {m !o}   does skip spaces
> {m ^o m} does not skip spaces
> 
> Since (a) can't always skip spaces, and (b) never skipping spaces leads
> to inconsistencies, and (c) only need to ignore spaces when the optional
> argument is last -- I strongly think xparse-alt has it right.

My main concern is "should we provide the option to change things"?
Would it be clearer if the same rules always apply (is there a need to
skip spaces to find trailing optional arguments, for example).
-- 
Joseph Wright