Hi Will,

I hope you are well.

> Consider:
>
>   \csname\ifnum 3 > 2 foo\fi\endcsname
>
> This (probably obviously to all of you) complains with the standard "Missing
> \endcsname inserted." presumably because there's an unexpandable implicit
> \relax inserted somewhere in there.

It doesn't. Implicit \relax are inserted when the conditional is still
trying to get the end of its arguments and hits its matching \else or
\fi. Here, the rhs of the comparison ends either at "2 " if spaces
have catcode 10, or at "2 f" if spaces are ignored (or course, the f
is not part of the number).

Perhaps you meant

  \csname\ifnum 3>2\fi\endcsname

which indeeds does \csname\relax\endcsname, an error.

> In expl3 we've discussed the concept of "restricted expandability", which
> refers to an expandable function that doesn't fully expand inside an "f"
> function (which is expandable \romannumeral-style expansion).
>
> Does it make sense to also indicate how/where expandable functions won't
> behave correctly inside "c" arguments? I must admit I haven't considered the
> ramifications of what these mean entirely. It does seem there's not
> necessarily much overlap between the f-unexpandable functions and the
> c-unexpandable ones.

I believe that all expandable and restricted-expandable functions will
behave correctly within a csname, as long as their result is made of
characters. For instance,

  \use:c { \tl_reverse:n { \relax } }

would of course not work, but that's not the "fault" of \tl_reverse:n.

If we have a problem with csnames, it's that they expand more strongly
than x-expansion, hence don't respect protected macros.

Cheers,
Bruno