## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Forum View Use Monospaced Font Show Text Part by Default Condense Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

```Hi,

Sorry for my delay in replying to this. Some context before my
comments. I'm afraid I've only been able to thinking a little about
the whole problem, but I wanted to jot down my thinking before it
evaporated.

IDEA 1:

> I tried to address the situation with the E specifier, which is the
> same as O except the braces are removed.

[snip]

IDEA 2:

> Here's a crazy idea. What if in the argument specifiers, we use a
> special symbol for denoting that the next argument is to be returned
> without braces? Such as for example \exp_args:N!o or so which would
> pass N unchanged and then ``unbrace'' the result of the o expansion.

[snip]

IDEA 3:

> However, it is my feeling that for most practical purposes you only
> wish to remove braces from the very last item in the expansion chain.
> Therefore, a simpler naming scheme such as
>  \exp_args_u:NO
>  \exp_args_u:NNo
>  etc.
> could be employed.

***

In order of preference, I think I like idea 1, then 2, then 3. It
seems like with the current system, we can't really anticipate every
possibility of weird expansion that comes along.

Arg specs n, N, w, D, e, E can be ignored for this discussion, so
here's what's left: (since an 'n' argument has no added braces)
o O
x X
C
f
d

(While I notice this, I think we should change 'd' to 'u' -- say -- to
avoid the similarity with 'D'.)

(Another thing: I search for \\[a-zA-Z_]*:[a-zA-Z]*X and I don't think
there are any 'X' variants defined anywhere, even in l3expan. I'll
probably remove it from the expl3 documentation soon-ish.)

'e' and 'E' take the place of unbraced 'o' and 'O'.
But that still leaves

'x' -- 'X' could now have a changed meaning to mean "unbraced"
'f' -- 'F' to follow the same logic
'd' -- Hmmm ('u' and 'U' might work)
'C' -- Hmmm
(And what about the hypothetical "make csname and expand twice"
scenario, etc.?)

So it looks like it gets pretty messy dealing with all these extra
letters.

In which case Morten's '!' idea sounds pretty good.

Generally I'm somewhat opposed to referring to the handling of the
arguments in the main name of the function.

But my thoughts are all fairly uninformed, without much experience of
actually writing any expansion code.

Must run with this email slightly unfinished,
Will
```