CTFE and DI: The Crossroads of D

Adam Wilson flyboynw at gmail.com
Wed May 9 20:30:21 PDT 2012


On Wed, 09 May 2012 20:17:17 -0700, Michaël Larouche  
<michael.larouche at gmail.com> wrote:

> On Thursday, 10 May 2012 at 02:59:22 UTC, Andrei Alexandrescu wrote:
>> On 5/9/12 3:14 PM, Steven Schveighoffer wrote:
>>> On Wed, 09 May 2012 15:57:46 -0400, Adam D. Ruppe
>>> <destructionator at gmail.com> wrote:
>>>
>>>> The real WTF is we use .di files for druntime in the
>>>> first place. It is performance sensitive and open source.
>>>>
>>>> We should be using the actual sources for inlining, ctfe,
>>>> etc. anyway.
>>>>
>>>> Let's not torpedo the .di patch's value for just phobos.
>>>
>>> I agree (although not generating .di files does not fix all the  
>>> problems
>>> of inlining and ctfe -- there are many stubbed functions even in the .d
>>> files).
>>>
>>> In my opinion, .di generation should by default generate fully-stripped
>>> code except for templates. If you want functions to be CTFE-able, don't
>>> use auto-generated .di files to import them.
>>>
>>> -Steve
>>
>> Actually the point here is to still be able to benefit of di automated  
>> generation while opportunistically marking certain functions as "put  
>> the body in the .di file".
>>
>> @inline anyone?
>>
>>
>> Andrei
>
> I find the @inline confusing, people could mistook it with a force  
> inline attribute.
>
> Something like @compiletime would be more clear for the tool and the  
> user.

I had the thought to use @embed, it's short, not taken, and you are embed  
the function in the DI file. Another option is @include although that one  
could be ambiguous.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/


More information about the Digitalmars-d mailing list