DIP 1006 - Preliminary Review Round 1

[Paolo Invernizzi]

On Wednesday, 7 March 2018 at 16:04:50 UTC, Timon Gehr wrote:
> On 07.03.2018 16:30, Paolo Invernizzi wrote:
>> On Wednesday, 7 March 2018 at 15:26:01 UTC, Timon Gehr wrote:
>>> On 07.03.2018 15:08, Paolo Invernizzi wrote:
>>>> On Wednesday, 7 March 2018 at 13:55:11 UTC, Jonathan M Davis 
>>>> wrote:
>>>>> [...]
>>>>
>>>> Jonathan, I understand your point, but still I can't find an 
>>>> answer to clarify my doubts.
>>>>
>>>> Are we asking for no UB in @safe code?
>>>> Are we asking for UB in @safe code but constrained to no 
>>>> memory corruptions?
>>>>
>>>> /Paolo
>>>
>>> UB is unconstrained by definition. If it is constrained, it 
>>> is not UB.
>> 
>> That! Thanks!
>> 
>> So, @safe code is code where UB should not be possible?
>
> Yes. (If you have UB, memory corruption is one of the allowed 
> outcomes, but @safe should not allow memory corruption. So 
> @safe needs to at least ban UB. According to Walter @safe needs 
> to ban memory corruption but not more. Therefore, as memory 
> corruption leads to UB (it is impractical to specify anything 
> else, at least for writes), @safe bans UB and nothing else.)
>
> Also note that even in @system code I don't want asserts to 
> cause UB in release. There should be an @system facility for 
> this purpose. (The situation is different than with bounds 
> checks: if bounds checks fail, there will always be a bad 
> memory access, which is UB, but with asserts it's always 
> possible that the assert itself was wrong and the code itself 
> will not trigger UB.)
>
>> Is it pragmatically possible to reach that goal?
>> 
>> /Paolo
>
> Yes. (Languages can be type safe and type systems can be 
> arbitrarily powerful.) It is certainly possible to _aim_ for 
> that goal, which Walter and Andrei have done on other occasions.

Thanks Timon, now everything it's definitely more clear to me on 
that matter.

I think a good compromise is to just totally ignore assert in 
release during optimization as a default, and use a compiler flag 
to let the optimiser peek to them, if a user want to explore that 
potential gain.

Just like '-boundscheck'.

Thanks to all for having clarified that point to me (and 
hopefully to others also!)

/Paolo