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?


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?


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!)


Reply via email to