forcing compile time function execution

[Joshua Reusch]

Am 27.12.2011 21:27, schrieb Vladimir Panteleev:
> On Tuesday, 27 December 2011 at 20:11:32 UTC, Joshua Reusch wrote:
>> Am 27.12.2011 20:51, schrieb Vladimir Panteleev:
>>> On Tuesday, 27 December 2011 at 19:46:31 UTC, Joshua Reusch wrote:
>>>> Am 27.12.2011 20:35, Vladimir Panteleev wrote:
>>>>> Halting problem?
>>>>
>>>> Makes an not-stopping pure function really sense?
>>>
>>> No, but you don't know if the user is expecting the function to take a
>>> long time to run, or it's stuck due to a bug.
>>>
>>
>> If the function gets evaluated at compile-time, also the
>> loop/recursion conditions are known.
>
> We're back at the halting problem. There are heuristics, but you can't
> know for sure.
>

Sorry, of course... Some other attribute (@ctfe) would really be better 
for this...

> For example:
>
> for (auto i=arr.length-1; i>=0; i--)
>
> On 64-bits, i will be 64 bits too (because arr.length is size_t). Since
> it's unsigned, the loop will wrap, and it'll take a very long time until
> it'll reach a state it's been in before.

Joshua