plans for macros
askme at me.com
Fri May 16 00:13:27 PDT 2008
Yigal Chripun wrote:
> janderson wrote:
> > Just a though. Couldn't templates simply be extended to handle macro
>> cases so that we get supper powerful templates rather then another
>> feature that works independently.
>> ie I see macros working like:
>> macro void MyMacro(foo)
>> MyMacro(X + 5 * 10);
>> Where as we could make a template do the same job,
>> void MyMacro(alias foo)()
>> MyMacro!(X + 5 * 10); //Compiler figures that it can drop the second ()
>> because its zero params.
>> Any cases that you need for a macro should be put into templates instead
>> IMHO. That will give up the flexibility to combine the power of the
>> template with the syntax sugar of a macro.
> first, I'd also try using a mixin to solve this.
> socond, I too think that having macros as an independent new feature
> adds unneeded redundancy. I think that macros would provide a super set
> of the abilities of templates, so I suggest, instead of you proposal of
> adding macro capabilities to templates, to do the exact opposite.
> i.e. provide an "upgrade path" from your current template solution to
> the more general macro solution. the current syntax will still work, but
> the compiler would allow the user to also treat a template as a macro.
> the end result should be, that the client code could make use of the
> syntax sugar of macros even if the current implementation is a template.
I pretty much think we are saying the same thing except on one point.
The only problem I have with switching the definition part of the code
to a macro syntax is that all the code we have already written in
templates becomes either deprecated or alternatively we have a bloated
language. I think adding a couple of extra bits of syntax sugar to
templates is the way to go. As the community discover some other
features that map well into "macros"/templates should the design branch
yet again (ie give it a even newer name)?
More information about the Digitalmars-d-learn