![](https://secure.gravatar.com/avatar/b03f5bc06e8f0abab0061774a597df9b.jpg?s=120&d=mm&r=g)
On 17/05/2018 00:12, Ross Moore wrote:
Hi Karl, and others.
On May 17, 2018, at 8:57 AM, Karl Berry
mailto:karl@freefriends.org> wrote: Doing a grep on /usr/local/texlive/2018/texmf-dist/tex/, I see \expanded is used in a couple oberdiek packages, context, and mathspec. I did not try to figure out if the mathspec usage is compatible. It might be worth notifying its author at some point as a courtesy. FWIW ...
Is \expanded really equivalent to that xelatex definition below:
xelatex/mathspec/mathspec.sty:129:\providecommand\expanded[1]{\edef\@tempa{#1}\@tempa}
It seems to me that it should be, but maybe there is actually a slight difference. So it would be nice to see some practical applications; e.g., where a package author had a specific desire, or absolute need (?), to avoid going via a temporary container-like macro such as \@tempa above.
Otherwise, why the need for this as a primitive? Convenience only, is not normally a good enough reason to add a primitive.
Hello Ross, The primitive definition differs from the \edef version in that - It does not double # tokens - It is expandable The latter is the big thing, and the reason the team have asked that this long-standing suggestion be added to engines. At present, if you want to arrange for 'function-like' behaviour, you can use \romannumeral to expand material \def\foo#1{\expandafter\fooaux\romannumeral-`q#1 } which will work but only up to the first non-expandable item in #1 (and also looses any leading spaces). The result is that if you wish to write expandable functions which are themselves expandable, you need to be careful in how everything is constructed such that nothing is 'output' until all processing is done. That often comes with a code complexity and performance cost, and is not always achievable. (See the various 'f-type expandable' functions in expl3.) An \expanded primitive makes it much more convenient to create such approaches, and matches the expansion carried out by e.g. \pdfstrcmp. For the work of the team in expl3, this would significantly aid consistency and allow more 'easy' expandable programming. The code addition is also small compared with many other 'new' (post-e-TeX) primitives, and \expanded is already present in LuaTeX. As such, we hope that the request can be actioned: we will make similar requests for XeTeX and (u)pTeX, such that all major engines have the functionality. Regards, Joseph