December 31, 2011
On Sat, 31 Dec 2011 03:40:43 +0200, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> Take a pick of any examples posted on this ML.  They are far better
> fit to use as a test bed.  Ideally one that does number crunching and
> can't be easily folded away.

I don't understand your point btw, why it shouldn't be easily folded away?
@inline is exactly for that reason, why would i pay for something i don't want?
December 31, 2011
On 12/30/2011 5:59 PM, so wrote:
> Well not them but another dummy function, i didn't think it would differ this much.

It differs that much because once it is inlined, the optimizer deletes it because it does nothing.

I don't think it is a valid test.
December 31, 2011
On Sat, 31 Dec 2011 04:30:01 +0200, Walter Bright <newshound2@digitalmars.com> wrote:

> On 12/30/2011 5:59 PM, so wrote:
>> Well not them but another dummy function, i didn't think it would differ this much.
>
> It differs that much because once it is inlined, the optimizer deletes it because it does nothing.
>
> I don't think it is a valid test.

Yes i can see from asm output but are we talking about same thing?
@inline IS all about that. We can try it with any example, one outperforming the other is not the point.

for(....)
   fun()

With or without @inline i know fun should/will get folded away, then why should i pay for the function call?
December 31, 2011
On 12/31/2011 03:16 AM, Andrei Alexandrescu wrote:
> On 12/30/11 6:25 PM, Timon Gehr wrote:
>> I'd be happy to extend the system, but currently I don't see it fall
>> short any of the three requirements. Can you help me out?
>
> I think it would be great to reproduce the expansion semantics of ddoc.
>
> Andrei

So basically, just breaking infinite recursion on recursive identical instantiations?

In what way does such a feature improve the expressiveness of the macro system?
December 31, 2011
On 12/30/2011 6:35 PM, so wrote:
> With or without @inline i know fun should/will get folded away, then why should
> i pay for the function call?

Because if the function did anything useful, the overhead of the function call is insignificant.

I don't think that dealing with large, complex functions that do nothing merits a language extension.
December 31, 2011
On 12/30/2011 6:59 PM, Timon Gehr wrote:
> On 12/31/2011 03:16 AM, Andrei Alexandrescu wrote:
>> On 12/30/11 6:25 PM, Timon Gehr wrote:
>>> I'd be happy to extend the system, but currently I don't see it fall
>>> short any of the three requirements. Can you help me out?
>>
>> I think it would be great to reproduce the expansion semantics of ddoc.
>>
>> Andrei
>
> So basically, just breaking infinite recursion on recursive identical
> instantiations?
>
> In what way does such a feature improve the expressiveness of the macro system?

Because inevitably someone will write:

#define FOO   a + FOO

and expect it to work (the correct expansion would be "a + FOO", not a stack overflow). The C preprocessor works this way, as do makefile macros, as Ddoc does.
December 31, 2011
On 12/31/2011 04:50 AM, Walter Bright wrote:
> On 12/30/2011 6:59 PM, Timon Gehr wrote:
>> On 12/31/2011 03:16 AM, Andrei Alexandrescu wrote:
>>> On 12/30/11 6:25 PM, Timon Gehr wrote:
>>>> I'd be happy to extend the system, but currently I don't see it fall
>>>> short any of the three requirements. Can you help me out?
>>>
>>> I think it would be great to reproduce the expansion semantics of ddoc.
>>>
>>> Andrei
>>
>> So basically, just breaking infinite recursion on recursive identical
>> instantiations?
>>
>> In what way does such a feature improve the expressiveness of the
>> macro system?
>
> Because inevitably someone will write:
>
> #define FOO a + FOO
>
> and expect it to work (the correct expansion would be "a + FOO", not a
> stack overflow). The C preprocessor works this way, as do makefile
> macros, as Ddoc does.

Makes sense, but why is it an issue if expansion is explicit?

enum FOO = q{a + FOO};

mixin(FOO);
December 31, 2011
On 12/30/2011 8:02 PM, Timon Gehr wrote:
> On 12/31/2011 04:50 AM, Walter Bright wrote:
>> Because inevitably someone will write:
>>
>> #define FOO a + FOO
>>
>> and expect it to work (the correct expansion would be "a + FOO", not a
>> stack overflow). The C preprocessor works this way, as do makefile
>> macros, as Ddoc does.
>
> Makes sense, but why is it an issue if expansion is explicit?
>
> enum FOO = q{a + FOO};
>
> mixin(FOO);

Because the expanded text is then rescanned for further macro replacement.

December 31, 2011
On 12/31/2011 05:19 AM, Walter Bright wrote:
> On 12/30/2011 8:02 PM, Timon Gehr wrote:
>> On 12/31/2011 04:50 AM, Walter Bright wrote:
>>> Because inevitably someone will write:
>>>
>>> #define FOO a + FOO
>>>
>>> and expect it to work (the correct expansion would be "a + FOO", not a
>>> stack overflow). The C preprocessor works this way, as do makefile
>>> macros, as Ddoc does.
>>
>> Makes sense, but why is it an issue if expansion is explicit?
>>
>> enum FOO = q{a + FOO};
>>
>> mixin(FOO);
>
> Because the expanded text is then rescanned for further macro replacement.
>

Yes, but in q{a + FOO} there is none.
December 31, 2011
On 12/30/2011 8:34 PM, Timon Gehr wrote:
> On 12/31/2011 05:19 AM, Walter Bright wrote:
>> On 12/30/2011 8:02 PM, Timon Gehr wrote:
>>> On 12/31/2011 04:50 AM, Walter Bright wrote:
>>>> Because inevitably someone will write:
>>>>
>>>> #define FOO a + FOO
>>>>
>>>> and expect it to work (the correct expansion would be "a + FOO", not a
>>>> stack overflow). The C preprocessor works this way, as do makefile
>>>> macros, as Ddoc does.
>>>
>>> Makes sense, but why is it an issue if expansion is explicit?
>>>
>>> enum FOO = q{a + FOO};
>>>
>>> mixin(FOO);
>>
>> Because the expanded text is then rescanned for further macro replacement.
>>
>
> Yes, but in q{a + FOO} there is none.

#define FOO a+Foo
FOO;

What is the text after macro expansion?