CTFE and DI: The Crossroads of D

[Adam Wilson]

On Wed, 09 May 2012 12:55:50 -0700, deadalnix <deadalnix at gmail.com> wrote:

> Le 09/05/2012 21:27, Adam Wilson a écrit :
>> Questions? Comments? Rants? Raves?
>> What do you think?
>>
>
> You miss the point of the importance of CTFE. It « just » allow us to  
> get the fastest possible regex engine given the regex is known at  
> compiletime (common case) for instance.

I was not trying to devalue CTFE, if anything I just don't know the cases  
in which it's used. But my point was, is that while CTFE allows for some  
very cool code. Complete Source DI's are a blocking bug for a significant  
chuck of the software development world.

> This is a major feature of D.
>
> Maybe an interpretable bytecode solution is the key. But clearly the  
> situation is not satisfying.
>
> Annotation could also be used to provide hint for the di generator. This  
> feature had great interest. And is something powerful we should build  
> on, when in place.
>
> Finally, di generator should do a part of the semaintic work to work  
> fine. auto must be resolved, and non CTFEable code could be safely  
> removed. This is already a major improvement.

This requires modifying significant chunks of the D semantic analysis  
engine and is a project that only a few people could pull off, I imagine  
that that list goes something like Walter, Don, Brad, and Kenji. It's  
doable, but the guys on that list have way bigger fish to fry and frankly,  
that seems like a sledgehammer solution to a needle-sized problem. I don't  
think we need to go that far right now.

My patch leaves auto-functions intact in DI so that D can do its analysis,  
and the non-CTFEable code problem can be solved by scrubbing Phobos of any  
reliance on DRT CTFE. It's a much simpler solution. For D3 we can tackle  
the big work.

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