On Thu, 10 May 2012 11:04:34 -0700, Jonathan M Davis <[email protected]>
wrote:
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%
modification.
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
http://www.thehorizonproject.org/
