[cfe-dev] Switching terminology from 'instantiation' to 'expansion' for macros?

Chandler Carruth chandlerc at google.com
Thu Jul 7 21:10:39 PDT 2011


On Thu, Jul 7, 2011 at 8:45 PM, John Freeman <jfreeman at cse.tamu.edu> wrote:

> On 7/7/11 8:49 PM, Chandler Carruth wrote:
> > Thoughts?
>
> I like all of it. I do have a question: is the term "expansion" also
> used in another case involving templates, like parameter packs?


Oof, yea, it is.

On the good side, the standard uses 'expansion' in that context almost
exclusively as 'pack expansion', a term defined in the standard. I suspect
any use we made of it in diagnostics could also be profitably tied to the
word 'pack'.

Also, both the C and C++ standards refer to 'macro expansion' to mean this.

Should
> we try to use a third term for macros in that case, like "substitution"
> (which is also used for templates (think "SFINAE");


Good idea, the C standard uses 'substitution' to describe the process
through which arguments to function-style macros are substituted into the
macro body (C99 6.10.3.1). We should at the least try to use 'substitution'
in the code surrounding this process in Clang IMO.

However, I don't think there are many contexts where we need or want to
distinguish between macro expansion and argument substitution, but i'd not
be opposed to using those two compound terms if that situation arises.

maybe there is no
> winning this battle)?
>

I'm fairly certain there is no perfect word. ;] That said, I like that both
macro expansion and argument substitution are mentioned in the standard.

The only other term I've thought about is 'replacement' as that's what the
standard uses in most cases. However, for diagnostics and thinking about how
the preprocessor works, I actually find 'expansion' much more helpful.
However, if others like the C standard's 'replacement' terminology, I'd be
down with that. =]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110707/84b3e132/attachment.html>


More information about the cfe-dev mailing list