Leandro Lucarella Wrote:

> According to phobos changeset 535[1] I guess we have a new 'manifest' keyword to define manifest (to be redundant) constants. I really think he should went with alias or macro or with other better *existing* keyword, but is definitely better than enum.
> 
> [1] http://www.dsource.org/projects/phobos/changeset/535

I wonder if now that we have "manifest" meaning "taking no storage space",
it could be made to work for functions too (inlining every call to the function).

On Sat, 22 Dec 2007 15:21:55 +0200, Hxal <hxal@freenode.d.channel> wrote:

> Leandro Lucarella Wrote:
>
>> According to phobos changeset 535[1] I guess we have a new 'manifest' keyword to define manifest (to be redundant) constants. I really think he should went with alias or macro or with other better *existing* keyword, but is definitely better than enum.
>>
>> [1] http://www.dsource.org/projects/phobos/changeset/535
>
> I wonder if now that we have "manifest" meaning "taking no storage space",
> it could be made to work for functions too (inlining every call to the function).

That would be great, but I think macros will do that better.
I think it's noteworthy that some languages like Delphi have an "inline" keyword for functions (and it works across units/modules).

-- 
Best regards,
 Vladimir                          mailto:thecybershadow@gmail.com

On 12/22/07, Hxal <hxal@freenode.d.channel> wrote:
> I wonder if now that we have "manifest" meaning "taking no storage space",
> it could be made to work for functions too (inlining every call to the function).

Why would you want to do that? I don't see why the programmer should need to know or care what gets inlined and what doesn't.

On Sat, 22 Dec 2007 19:08:37 +0200, Janice Caron <caron800@googlemail.com> wrote:

> On 12/22/07, Hxal <hxal@freenode.d.channel> wrote:
>> I wonder if now that we have "manifest" meaning "taking no storage space",
>> it could be made to work for functions too (inlining every call to the function).
>
> Why would you want to do that? I don't see why the programmer should need to know or care what gets inlined and what doesn't.

1) The compiler can't know which code is in more need of performance - this gives more control over performance to the user. Also, inlining doesn't just imply copying the machine code - the function call is substituted at the AST level, which means that it allows optimizations to happen across function boundaries.

2) Sometimes it's very useful for security. Reverse-engineering a 500kb function of mostly inlined cryphographic and mathematical operations is hell, and doesn't have any substantial negative effects (the worst part is the huge stack frame).

-- 
Best regards,
 Vladimir                          mailto:thecybershadow@gmail.com