CTFE and DI: The Crossroads of D
flyboynw at gmail.com
Wed May 9 15:16:17 PDT 2012
On Wed, 09 May 2012 15:03:21 -0700, Era Scarecrow <rtcvb32 at yahoo.com>
> 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
>> 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.
Theoretically D can compile Shared Libraries now. Which means that DI
files are going to be more useful than ever.
> 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
CTFE cannot currently call a function without it's source.
> 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..
The Horizon Project
More information about the Digitalmars-d