CTFE and DI: The Crossroads of D

[Timon Gehr]

On 05/09/2012 09:27 PM, Adam Wilson wrote:
>
> 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.
>

I don't see the point. Use whatever is convenient.

>
> A Potential Solution:
>
> In my estimation there is a solution that allows both features to retain
> their full functionality and only requires minimal rewrites to Phobos.
> However this solution CANNOT be statically enforced by the compiler,
> except though a better, more explicit, error message(s).
>
> The core of the solution is to disallow externally dependent CTFE in all
> modules accepted into Phobos. This would also require a clear and
> concise explanation accompanying the CTFE documentation stating that
> calling external code via CTFE will most likely result in a compiler error.
>
> The reason I am proposing this solution is that I would argue that the
> author of std.datetime choose to utilize CTFE against an external module
> (in this case, the DRuntime) when Walter has (to the best of my
> knowledge) explicitly stated that DI files in the future would not
> contain unneeded implementations and that the current DI implementation
> was essentially a hack to get *something* working. Looking at the DI
> generation code, I can tell you, it is definitely not meant to be
> permanent, it is filled with hard-coded idiosyncrasies (like it's
> ridiculous indenting) that had to be fixed.
>
> In essence I am arguing that it is their usage of CTFE that is
> incorrect, and not the fault of DI generation.

Debating whose fault it is is a waste of time, because there is no fault.

> As such, those modules
> should be rewritten in light of said assumptions changing. It is my
> opinion that
>

Make Phobos build and submit a patch? Why would there an explicit strict 
policy need to be stated when the auto tester will just catch all 
'offending' code?


> A longer term solution would be to give CTFE the ability to work on
> functions without the source code, so long as it mets the other rules of
> CTFE and can run the required code. However, there are some serious
> security issues that would need to be cleared up before this could work.
>

Security issues are a minor concern compared to actually making that work.