Joseph Wright wrote:
> My feeling is that \DeclareExpandableDocumentCommand, if implemented,
> would be explicitly marked up:
> 
> "In general, document commands should be created using
> \DeclareDocumentCommand. \DeclareExpandableDocumentCommand is intended
> to be used only in *exceptional* circumstances where a fully-expandable
> function is *essential*. It has very restricted processing
> possibilities, when compared to the standard version."
> 
> I'd then expect us to basically support s, o, O and m type arguments,
> with any one \long forcing all to be long (probably by insisting that
> any + has to come before the first arg. spec.). I need to look at how s
> and o grabbing is implemented in such cases, so the exact restrictions
> are "yet to be determined". I would imagine that there would be no post
> processing in this case. (Of course, if there are good examples of where
> this needs thinking about, it can be looked at again.)

I've taken a quick look at things. I think that, when done by hand you
can in principal support rather complex things (for example " s o m m o
s m m"), but that this looks horrible if done with an automated system.
Further, I don't want to encourage people to use this function unless
*necessary*, and so far the number of real cases is *very* small.

How would the following sound:

 - All arguments either short or long (I think this is the only way in
any case), with "+" then required in front of each letter if any one is
to be long so that the input syntax is clear. So "+m m" or "o +m" raise
an error, whereas "+m +o" is allowed.

- Support only a subset of the possibilities. With "m ... m"
representing "one or more m arguments":
  = m ... m
  = t<token> m ... m
  = D<token1><token2><default> m ... m
  = t<token> D<token1><token2><default> m ... m
only (with short-cuts s, o and O allowed in the same pattern). Perhaps
not even the last one?
-- 
Joseph Wright