janderson wrote:
 <Snip>
 > 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)
> {
>    foo;
> }
> 
> MyMacro(X + 5 * 10);
> 
> Where as we could make a template do the same job,
> 
> void MyMacro(alias foo)()
> {
>    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.
> 
> -Joel

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.

Yigal Chripun wrote:
> janderson wrote:
>  <Snip>
>  > 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)
>> {
>>    foo;
>> }
>>
>> MyMacro(X + 5 * 10);
>>
>> Where as we could make a template do the same job,
>>
>> void MyMacro(alias foo)()
>> {
>>    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.
>>
>> -Joel
> 
> 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)?

-Joel