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