DIP 1006 - Preliminary Review Round 1

[Timon Gehr]

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.