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.
