The following is quoted from Peter Grill's answer on question LaTeX dynamic macro definition.

The \expandafter is requried as the \newcommand needs to be dealt with after the \csname.

As a newbie in TeX programming, how to know whether or not I need \expandafter?

  • 1
    Thanks for reading my mind.. I was about to add a warning on my answer that this is the extent of my knowledge of expansion related issues so perhaps a follow up question on that issue would be appropriate. I am still a newbie for expansion issues, which are the cause of most of my problems. Jul 20 '12 at 6:04
  • 1
    In a lot of situations exactly one token is needed. This is especially true for assignmens like \def, \let, \newcommand, but some other primitives also require this, for instance \ifx or \show. \csname is one token and would mercilessly be accepted by all the examples I gave as the token to be dealt with, which is almost never what is intended. So if the token to be given is a control sequence to be constructed with \csname, that construct has to be expanded with \expandafter before the primitive is seen. Jul 20 '12 at 6:11
  • 3
    Word count for \expandafter in my DocScape sources is 1227, at 36621 lines of code. I guess about 10% of those are not really needed, so you could say 1100 \expandafters were needed to make DocScape (whatever that means ;-) Jul 20 '12 at 6:20
  • 1
    Interesting fact: this very question about how to use \expandafter to prepare arguments to other macros was the first thing I learned about basic TeX and also the reason I got the TeXbook to learn more.
    – Ryan Reich
    Jul 20 '12 at 10:22
  • 1
    @StephanLehmke: Is your record still 63 consecutive \expandafters? :-) Jul 24 '12 at 18:38

Let's look at three examples from latex.ltx (the LaTeX kernel).


\def\@namedef#1{\expandafter\def\csname #1\endcsname}

This is entirely analogous to the \expandafter\newcommand that's the main object of the question. With \@namedef{foo} we get

\expandafter\def\csname foo\endcsname

and the control sequence \foo is built before \def comes into action: the expansion of \csname is the symbolic token whose name is what comes after it up to the matching \endcsname (with complete expansion, but analyzing this would take too far).


  \iterate \let\iterate\relax}

We use this in the form

  <code A>
  <code B>

where \ifz is one of the TeX conditionals and <condition> is the test that, if true, will make the loop continue. This becomes

\def\iterate{<code A>\ifz<condition><code B>\relax\expandafter\iterate\fi}
\iterate \let\iterate\relax

The first line is an assignment: it's executed and removed from the input token list, leaving

\iterate \let\iterate\relax

Now \iterate is expanded, so we get

<code A>\ifz<condition><code B>\relax\expandafter\iterate\fi

TeX expands/executes <code A> and then evaluates the conditional. If it's false, everything up to \fi is skipped, so what remains is


The expansion of \fi is empty; the next assignment is executed, ending the loop. If it's true, then we obtain

<code B>\relax\expandafter\iterate\fi

Now <code B> is expanded/executed; \relax does nothing and we have the magic


Here \expandafter expands \fi, which has empty expansion: so TeX finds

\iterate \let\iterate\relax

and restarts. If the \expandafter were omitted, the \fi tokens would accumulate, possibly filling the memory on long loops.


Several commands in the kernel are defined following the scheme


which means that \@foo cannot be used past \begin{document}, where it would trigger the "Can be used only in the preamble" error. Let's see what \@onlypreamble does:


First \@preamblecmds is initialized to empty. If we say


we get


The first \expandafter expands the second, which expands the third; the last one, in turn, expands \@preamblecmds. If this was the first call of the macro \@onlypreamble, we'd get


To make the problem more interesting, let's call now


Again we get


but now the expansion of \@preamblecmds is \do\@foo: so finally we get


and so on for every call of \@preamblecmds. When LaTeX works on \begin{document} it says

\gdef\do#1{\global\let #1\@notprerr}\@preamblecmds

The \do command is defined to make its argument equivalent to \@notprerr (that triggers the above mentioned error); then \@preamblecmds is expanded, so that


(and many other tokens of the same type) will be executed.

In \@onlypreamble the \expandafter is needed to get the expansion of \@preamblecmds in the replacement text before redefining \@preamblecmds: doing


would lead to a disaster, because the final replacement text of \@preamblecmds would be


(with many other \do... combinations). And when the expansion of \@preamblecmds is performed, TeX would find \@preamblecmds and expand it, finding \@preamblecmds which it would expand, finding… Infinite loop. Oops!


The LaTeX kernel provides \@ifundefined that checks whether the control sequence having as name its argument is defined or not (actually, undefined means either really undefined or equivalent to \relax).


The \expandafter\@firstoftwo and \expandafter\@secondoftwo are explained elsewhere on the site; here the \expandafter application is similar to the first one: the usage is \@ifundefined{foo}{true}{false} and the control sequence token \foo is built before \ifx comes into action.

What I want to underline here is that generally using \expandafter\ifx is wrong: for instance, after


the test


would return false. So don't use \expandafter unless you know it's necessary.

  • 1
    In my understanding always using \expandafter in doubt cases is safe. If misuse of \expandafter is harmful, could you provide one example of it? Jul 20 '12 at 7:51
  • 1
    @HiggsBoson Using \expandafter when not necessary is not recommended; you're losing control on what gets expanded and when.
    – egreg
    Jul 20 '12 at 8:06

The short answer to this is that you need \expandafter whenever you need something expanded before the previous token (helpful, I know!). In Peter's example, the code was

\expandafter\newcommand \csname name#1\endcsname{\emph{#2}}

(where #1 and #2 were arguments to some surrounding macro). The reason you want \expandafter here is because the entire \csname construction is not itself a control sequence, and yet \newcommand expects the first thing after it to be a control sequence that will name the new command. Without \expandafter, it will grab \csname itself as the name of the new command, and then it will error out because it is not actually undefined.

The philosophy here is that the \csname is "preparation" for using \newcommand, and the \newcommand itself cannot be expanded meaningfully until the following input has been suitably prepared. The purpose of \expandafter is to reserve it while acting on some subsequent directive to transform the actual input into the desired one.


Not to compete with @egreg's answer but to answer your comment on when not to use \expandafter.



which defines \foo to be hello. So that is safe and good.


may not be wrong (but it may be, and often is).

If it's the common case that \foo is not yet defined then you will get the error

! Undefined control sequence.
l.1   \expandafter\def\foo

As the expandafter tries to expand \foo before the definition.

If on the other hand \foo already had the definition \def\foo{world} then


would give the error

! Missing control sequence inserted.
<inserted text> 
<to be read again> 
\foo ->w
l.3   \expandafter\def\foo

as it is equivalent to \def world{hello}

and finally if \foo already was defined by \def\foo{\bar} then you would get no error but it would define \bar not \foo which is good if that's what is intended, but may not be what is intended if you just add \expandafter "for luck".





> \foo=macro:
->\bar .
l.5 \show\foo

> \bar=macro:
l.6 \show\bar

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.