CTFE and DI: The Crossroads of D

[Christopher Bergqvist]

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.