[D-runtime] Why does druntime us .di files instead of .d?

[Steve Schveighoffer]

In fact, they are both shipped.  In order to use the .d files instead of the .di files change this argument in your dmd.conf file:

-I%@P%/../../src/druntime/import

to this:

-I%@P%/../../src/druntime/src


Note then, you have to be wary not to try and import some of the directories.  Such as rt and gc.


At least this can provide a test of how well CTFE will perform if we *did* switch to .d files.

Here's another idea:

What if .di put in a pragma indicating the original source of the file (auto generated by dmd -h)?  If the original source exists, then CTFE will use it instead of the .di file.

You know, thinking through this, the more I don't really understand why we are doing .di files *except* for object.di (which is hand-generated anyway).

-Steve


>________________________________
>From: Andrew Wiley <wiley.andrew.j at gmail.com>
>To: D's runtime library developers list <d-runtime at puremagic.com>
>Sent: Friday, July 15, 2011 12:31 AM
>Subject: Re: [D-runtime] Why does druntime us .di files instead of .d?
>
>
>On Thu, Jul 14, 2011 at 9:30 PM, Andrew Wiley <wiley.andrew.j at gmail.com> wrote:
>
>
>>
>>
>>On Thu, Jul 14, 2011 at 6:19 PM, Walter Bright <walter at digitalmars.com> wrote:
>>
>>
>>>
>>>On 7/14/2011 2:40 PM, Andrew Wiley wrote:
>>>
>>>
>>>>It seems to me that a way to fix all this and guarantee CTFE-ability (which seems to be the end goal) would be to add some sort of modifier or annotation to designate that a function is CTFE-able.
>>>>
>>>
>>>
Please, please, no! I hate "constexpr" in C++0x. One of the whole point of CTFE is it "just works" on regular D functions.
>>
>>
>>I think that's excellent as well, and to be honest I don't think an annotation is a good solution, but we're going to have to come up with something here because it isn't "just working."
>>
>>
>>CTFE, traits, and mixins together make D a powerhouse for compile-time code generation, and that's pretty much what's kept me around here :D
>
>
>
>
>Could we just ship both d and di files, and make the frontend able to switch to the .d file when it needs the function source? 
>
>_______________________________________________
>D-runtime mailing list
>D-runtime at puremagic.com
>http://lists.puremagic.com/mailman/listinfo/d-runtime
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d-runtime/attachments/20110715/628bd33e/attachment-0001.html>