On Wednesday, 9 May 2012 at 19:27:19 UTC, Adam Wilson wrote:
The problem is thus: CTFE requires that any function that it
could possibly evaluated by CTFE, must retain it's
implementation. Unfortunately, there is simply no way for the
DI generation system to know which functions are capable of
being called by CTFE and which ones actually are.
This limitation is due to the fact that DI generation must be
run before Semantic Analysis because said analysis may perform
significant rewrites of the AST. There is even a large (for
DMD) comment in the main function of DMD explaining that DI
generation should not be moved from where it is due to the
inconsistencies that could arise.
The patch I created currently fails in the autotester because
the template function dur() in the druntime is called via CTFE
from Phobos. Per the community agreed upon DI rules, the
function implementation of the Duration constructor that is
called by the dur() function is stripped away and CTFE fails.
We as a community need to decide how important these two
features are. Here are the Pro's of each feature as I see it. I
encourage you to add to this list and debate the merits of
each.
Pro's for DI:
Shared libraries are useless without proper header-style
interfaces to the code.
Can reduce compile time.
Required by business so as not to share the entire code-base of
their product.
Pro's of CTFE:
Makes writing certain types of otherwise complicated code
simple.
Very useful to systems programmers.
By my view of it, lack of DI is a major blocker to any business
looking to use D, including mine; and that CTFE is just
"nice-to-have". And I would argue that if D wants to see any
real usage above the 0.3% it got on the May TIOBE index, it
needs serious business investment in using the language. My
company would love to use D, but we can't because we don't want
to release our entire code-base; hence my work on the DI
generation patch. I would suggest to you that almost every
business looking at D is going to find the current DI situation
... untenable.
Perhaps I missed something as I'm reading this.
Why would this be such a big deal? As I understand it some of
this comes from D couldn't compile to libraries (if that's
different now I am not sure, haven't kept up with all the
updates) so everything in phobos is distributed as source.
If we can't compile to a callable library (static or dynamic)
for a while and can't use CTFE on non-source, then the problem is
more explicitly present and either needs a workaround or some
type of convention.
However IF we can compile to libraries and those compiled
libraries are exported out with the .di files (I'd personally
require the .di file information also bs part of the library as a
public string, so you can't mix up wrong versions of .di files,
which you can then extract) why then that a problem? The binary
execution code is already available and we should be able to call
it through the compiler as long as the interfaces are used
properly. I see this only as a partial problem being as the
compiler is written in C++ and not D.
Course there are security issues, if a module harbored a virus
and using CTFE or calling those functions unleashed it, assuming
the program had permissions to do any damage... At which time the
compiler would need very low permissions (or it's own UID)
allowed to run so in those cases it could crash gracefully...
Perhaps I'm just rambling now..
