CTFE and DI: The Crossroads of D

[deadalnix]

Le 10/05/2012 20:01, Adam Wilson a écrit :
> 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.
>

Frankly, the compiler shouldn't do that. It's internal structure isn't 
made to do such stuff and it will do a poor job here.