CTFE and DI: The Crossroads of D

[Adam Wilson]

On Thu, 10 May 2012 10:57:37 -0700, Christopher Bergqvist  
<spambox0 at digitalpoetry.se> wrote:

> On Thursday, 10 May 2012 at 17:37:59 UTC, Adam Wilson wrote:
>> On Thu, 10 May 2012 09:56:06 -0700, Steven Schveighoffer  
>> <schveiguy at yahoo.com> wrote:
>>
>>> 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
>>
>> Exactly this. I am currently in the process of changing the DRuntime  
>> makefiles such that some of the files are not processed as DI's. This  
>> allows Phobos CTFE dependencies on the DRT to remain valid while still  
>> allowing DI's to be generated for parts where they matter, with the  
>> goal of making both a shared and static library build of the DRT. The  
>> tool I am using to accomplish this feat? cp. It works, it delivers  
>> exactly what we need and it's *is not* a broken operation like the  
>> current DI generation.
>>
>> Like Steve said, most people generating DI files are not really worried  
>> about CTFE working, in fact they almost undoubtedly *know* that they  
>> are breaking CTFE, yet they choose to do it anyways. They have their  
>> reasons, and frankly, it doesn't concern us as compiler writers if  
>> those reasons don't line up with our personal moral world-view. Our job  
>> is to provide a tool that DOES WHAT PEOPLE EXPECT. Otherwise they will  
>> move on to one that does. If people expected DI generation to be  
>> glorified (and not broken) copy operation, they would (and do) use cp.
>
> How about:
> dmd -H mySource.d --keepImplementation MyClass.fooMethod
> ?
>
> It should be good enough for makefiles as in the case of core.time/dur,  
> but get's a bit hairy with overloads (append "[0]" to select specific  
> ones?).  Maybe it requires semantic information though.

It does require some semantic information. And the solution I've seen seen  
most talked about here is some kind of attribute similar to @pure that  
tells the compiler to include the implementation in the DI file. IMO, this  
is a fine solution, but the compiler cannot be involved the decision to  
keep an implementation in or out based on anything other than programmer  
directives because the compiler just don't know what's being depended on.  
That's how we ended up where we are today, DI files are the source with  
unittests and comments removed.

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