On Wed, Mar 27, 2013 at 10:19:12PM +0100, Timon Gehr wrote:
> On 03/27/2013 06:50 PM, H. S. Teoh wrote:
> >On Wed, Mar 27, 2013 at 06:29:59PM +0100, Timon Gehr wrote:
> >>On 03/27/2013 06:20 PM, H. S. Teoh wrote:
> >>>On Wed, Mar 27, 2013 at 05:55:54PM +0100, Timon Gehr wrote: [...]
> >>>>If CTFE does not terminate, compilation is not allowed to succeed.
> >>>
> >>>Heh, I think this one is unimplementable, as it amounts to solving
> >>>the halting problem. :)
> >>>...
> >>
> >>Actually it does not. Non-success denotes either failure or non-termination.
> >
> >But how do you check for non-termination?
[...]
> 
> Why would you need to?

How else would you force compilation to fail in that case?


T

-- 
In order to understand recursion you must first understand recursion.

On 03/27/2013 10:37 PM, H. S. Teoh wrote:
> On Wed, Mar 27, 2013 at 10:19:12PM +0100, Timon Gehr wrote:
>> On 03/27/2013 06:50 PM, H. S. Teoh wrote:
>>> On Wed, Mar 27, 2013 at 06:29:59PM +0100, Timon Gehr wrote:
>>>> On 03/27/2013 06:20 PM, H. S. Teoh wrote:
>>>>> On Wed, Mar 27, 2013 at 05:55:54PM +0100, Timon Gehr wrote:
>>>>> [...]
>>>>>> If CTFE does not terminate, compilation is not allowed to succeed.
>>>>>
>>>>> Heh, I think this one is unimplementable, as it amounts to solving
>>>>> the halting problem. :)
>>>>> ...
>>>>
>>>> Actually it does not. Non-success denotes either failure or
>>>> non-termination.
>>>
>>> But how do you check for non-termination?
> [...]
>>
>> Why would you need to?
>
> How else would you force compilation to fail in that case?
>
>
> T
>

You don't have to.

"If CTFE does not terminate, compilation is not allowed to succeed."

&&

"Non-success denotes either failure or non-termination."

==>

"If CTFE does not terminate, compilation should either fail or not terminate."

On 03/27/2013 05:55 PM, Timon Gehr wrote:
> ...
>
>   - No mutable variables/fields are loaded or stored that were not
>     allocated during the same CTFE execution.
>...

On second thought, probably loading of the value of initialized mutable static variables should be allowed, so that it is easy to assemble mutable object graphs at compile time. (it would still not be allowed to modify the fields of referenced objects.)

On 03/27/2013 05:55 PM, Timon Gehr wrote:
> ...
>
>   - Only type casts are evaluated whose kind may not harm type safety.
> ...

This could easily be lifted as well by doing a more "runtime" checks (in such a way that there is no additional overhead for the interpreter except when there is an out-of-bounds access, which would terminate CTFE anyway and in the final sanity check when the resulting value is returned.)

On Wednesday, 27 March 2013 at 19:43:13 UTC, Dmitry Olshansky wrote:
> 27-Mar-2013 23:14, Peter Alexander пишет:
>> On Wednesday, 27 March 2013 at 14:48:32 UTC, Andrei Alexandrescu wrote:
>>> Found this:
>>> http://stackoverflow.com/questions/15652718/object-error-access-violation-when-printing-result-of-std-algorithm-cartesianpr
>>>
>>>
>>> Soon we'll need to clearly define the limits of CTFE, and what happens
>>> when it fails.
>>
>> Aren't the limits just Safe D? (i.e. if it's in Safe D, it compiles,
>> anything more is implementation defined?)
>
> No - one can call writeln (if one day it's marked @trusted). CTFE can never do such a thing. Plus no access to globals etc. in general sense no side effects.

Actually the relationship between CTFE and SafeD is more interesting than that. CTFE can also do some things which safe D cannot, eg pointer arithmetic.

Neither is a pure subset of the other.