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
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
UB is unconstrained by definition. If it is constrained, it
is not UB.
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
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
Just like '-boundscheck'.
Thanks to all for having clarified that point to me (and
hopefully to others also!)