CTFE and DI: The Crossroads of D

Steven Schveighoffer schveiguy at yahoo.com
Thu May 10 09:56:06 PDT 2012


On Thu, 10 May 2012 12:04:44 -0400, deadalnix <deadalnix at gmail.com> wrote:

> Le 10/05/2012 17:54, Steven Schveighoffer a écrit :
>> On Thu, 10 May 2012 10:47:59 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> On 5/10/12 6:17 AM, Steven Schveighoffer wrote:
>>>> On Wed, 09 May 2012 23:00:07 -0400, Andrei Alexandrescu
>>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>>> 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".
>>>>
>>>> If you aren't going to strip the files, I don't see the point in it.
>>>
>>> Inlining.
>>
>> No, I mean if dmd -H isn't going to strip the files, what is the point
>> of dmd -H? I can already copy the .d to .di and have inlining/ctfe, or
>> simply use the .d directly.
>>
>> At this point, in order to get CTFE to work, you have to keep just about
>> everything, including private imports. If we want to ensure CTFE works,
>> dmd -H becomes a glorified cp. If we have some half-assed guess at what
>> could be CTFE'd (which is growing by the day), then it's likely to not
>> fit with the goals of the developer running dmd -H.
>>
>> -Steve
>
> If you can CTFE, you can know what is CTFEable. If it is currently half  
> assed, then work on it and provide a better tool.

There is already a better tool -- cp.  I ask again, what is the benefit of  
.di generation if it is mostly a glorified (faulty?) copy operation?

As Adam points out in his original post, ensuring CTFE availability may  
not be (and is likely not) why you are creating a .di file.

Plus, what isn't CTFEable today may be CTFEable tomorrow.

inlining is one thing, because that's an optimization that has a valid  
fallback.  CTFE does not.

-Steve


More information about the Digitalmars-d mailing list