Why CTFE is context-sensitive?

[Brad Roberts]

On 1/27/14 10:40 AM, Pierre Talbot wrote:
> On Monday, 27 January 2014 at 01:39:47 UTC, Simen Kjærås wrote:
>> On 2014-01-26 09:59, Pierre Talbot wrote:> Hi,
>> >
>> > I was wondering why CTFE is context sensitive, why don't we
>> check
>> > every expressions and run the CTFE if it applies?
>>
>> Mostly because it's not necessary, and takes more time than simply compiling it. For an
>> optimization step, opportunistic CTFE would certainly be possible (it is, after all, simply
>> constant folding on steroids).
>>
>> The situations in which CTFE is attempted today are when it's explicitly required - either because
>> the value is used at compile time, or because it's assigned to a manifest constant or static
>> variable (which are defined to be required to be known at compile time).
>>
>> This means the compiler does not need to spend inordinate amounts of time testing to see if the
>> code compiles with CTFE, and that it can give sensible error messages when something cannot be
>> CTFE'd. If instead opportunistic CTFE were the norm, you would need to disassemble your program to
>> see if the compiler did in fact CTFE the code that you think it should.
>>
>> --
>>   Simen
>
> We could do opportunistic CTFE by default, and if the user want to ensure it is done, instead of
> disassemble the program, he could just use the usual techniques (static, ...).
>
> But ok, what I wanted to hear is that it is theoretically possible but technically problematic.
>
> Thanks to all,
> Pierre

One of the problems is on the opposite side, ensuring it's NOT done when you don't want it to be. 
Consider an example where you have a blob of obfuscated data and a de-obfuscation routine.  It 
_could_ be executed at compile time, but that defeats the point.  What we have right now puts the 
control in the hands of the developer.