CTFE and DI: The Crossroads of D

[Era Scarecrow]

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..