CTFE and DI: The Crossroads of D

[Adam Wilson]

On Wed, 09 May 2012 15:03:21 -0700, Era Scarecrow <rtcvb32 at yahoo.com>  
wrote:

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

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

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


-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/