CTFE and DI: The Crossroads of D

Adam Wilson flyboynw at gmail.com
Thu May 10 11:21:49 PDT 2012

On Thu, 10 May 2012 11:04:34 -0700, Jonathan M Davis <jmdavisProg at gmx.com>  

> On Thursday, May 10, 2012 10:37:58 Adam Wilson wrote:
>> 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.
> Actually, I expect that they _don't_ know in most cases until they've  
> actually
> done it and had any CTFE stuff that they do break (or nothing break if  
> they
> don't use CTFE).
> However, ultimately, if you decide to use .di files, you _are_ choosing  
> between
> having a stripped interface and having CTFE and inlinability. So, even  
> if the
> programmer is not fully aware of the tradeoffs when they first attempt  
> it,
> that's ultimately what they have to decide.

Yes they well, but to be honest, I've never met a competent native  
language programmer who didn't understand that using something like DI  
files was going to be a trade-off at some level, they might not know to  
what degree initially, but the understanding is there. More importantly  
the user is already expecting some things to not work with that model so  
the won't be shocked when something actually doesn't.

> Honestly, I think that if you really want to be using .di files though,  
> in most
> cases, you're going to have to maintain them by hand. As such, you  
> basically
> have the choice between copying the .d file and then stripping it down  
> by hand
> or using the tool to strip it and then adding stuff back in by hand. I  
> really
> think that druntime's choice of automatically generating .di files as  
> part of
> the build process is a flawed idea in the general case. But it looks like
> you've started the process of changing how druntime deals with that.

Well the DI generator does a few things intelligently now so that you  
don't have to hand modify as much, namely keeping implementations for auto  
functions and template functions while stripping the rest. I tried to  
balance out what was needed to make it work at all with what is expected  
by it's likely users. I think this patch will cover 95% of the DI use  
cases out there. And 5% modifications beats the pants off of 100%  

> I would warn you however that taking the approach of just copying the
> implementation over for what Phobos needs for CTFE is inherently flawed  
> and
> will undoubtedly break existing programs. I'd argue that for the most  
> part,
> anything that currently has its implementation in druntime's .di files  
> needs to
> keep it. The sole exceptions would be stuff which isn't CTFEable (e.g.  
> the rt
> stuff) and stuff which already has a hand-written .di file (like object  
> and
> thread). So, you should be erring on the side of not generating the .di  
> file
> with your updated .di generator rather than using it as far as druntime  
> goes.
> - Jonathan M Davis

I am actually in the process of doing just that. I've removed some of the  
DRT files from DI generation; most of core.* and all of core.stdc.*. I am  
taking it slow so that I can be deliberate about my testing precisely  
because the DRT is the foundation of every D program in existence, and I  
don't want to break them. For now I've removed the things that can be  
pretty obviously removed. However, the goal is to make the DRT a shared  
library, and that means that somethings will necessarily require DI files  
so they don't get accidentally built in the program and a create a problem  
of incompatible version; but mostly that stuff is, as you mentioned, the  
actual runtime parts.

Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project

More information about the Digitalmars-d mailing list