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.

Reply via email to