inlining...

Manu turkeyman at gmail.com
Tue Mar 18 05:02:56 PDT 2014


On 18 March 2014 06:37, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org>wrote:

> On 3/17/14, 9:10 AM, Manu wrote:
>
>> On 18 March 2014 01:36, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org <mailto:SeeWebsiteForEmail at erdani.org>>
>>
>> wrote:
>>
>>
>>     I'd like to see a solution to inlining along the lines of "pliz pliz
>>     inline" (best effort) and "never inline".
>>
>>     Outlining only at a specific call site is seldom needed and when it
>>     is it's trivially achievable with a noinline function forwarding to
>>     the inline function. Inlining only at a specific call site is a tall
>>     order and essentially impossible if header generation had been used.
>>
>>
>> I don't follow, how does that work?
>> It's the key innovation here. Since D doesn't have macros, I think it's
>> something that really needs to be supported nicely.
>> Obviously it's impossible if source is unavailable. It should give the
>> same complaints that CTFE gives when source is unavailable.
>>
>
> The notion that a compiler can ask for any function to be inlined without
> the compiler having been "warned" in the function declaration makes me
> uncomfortable about feasibility.
>
> However, upon further thinking the same happens with CTFE.


Exactly, we already have it in CTFE. It doesn't really add any new concept
that D isn't already comfortable with.
It can kinda be seen as sort of a type safe macro, which is a tool that D
is lacking compared to C. I think the mixin keyword and concept makes
perfect sense in this context. It feels quite intuitive to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140318/8b91dbdd/attachment.html>


More information about the Digitalmars-d mailing list