CTFE and DI: The Crossroads of D

[deadalnix]

Le 09/05/2012 22:58, Adam Wilson a écrit :
> On Wed, 09 May 2012 13:51:22 -0700, Jonathan M Davis
> <jmdavisProg at gmx.com> wrote:
>
>> On Wednesday, May 09, 2012 22:46:58 foobar wrote:
>>> This makes sense.
>>> So this means the datetime example would fail to compile when
>>> using druntime's .di files. This should be emphasized in the
>>> spec/docs to minimize the chance for gotchas for users.
>>>
>>> We could add an exception to this rule by tagging functions with
>>> e.g. "export". What do you think?
>>
>> export already has another meaning. It also goes against the whole
>> idea that
>> any function is supposed to be CTFEable without special annotations.
>>
>> - Jonathan M Davis
>
> I think an attribute like @implementation would be useful here. It could
> easily be used by the DI generator to keep the implementation in the DI
> file. You would only need to apply it to functions that you want to be
> CTFEable externally, internal CTFE would still work the same.
>

It is reversed logic. The more code you have available, the better for 
the compiler and the user.

Code should be stripped only if a reason tells us to do so (compile 
time, source code shouldn't be released, etc . . .).