On Thursday, 10 April 2014 at 15:00:34 UTC, Steven Schveighoffer
wrote:
On Thu, 10 Apr 2014 10:55:26 -0400, Tommi
<tommitiss...@hotmail.com> wrote:
On Thursday, 10 April 2014 at 14:13:30 UTC, Steven
Schveighoffer wrote:
On Wed, 09 Apr 2014 13:35:43 -0400, David Nadlinger
<c...@klickverbot.at> wrote:
On Tuesday, 8 April 2014 at 20:50:35 UTC, Steven
Schveighoffer wrote:
This does not sound correct. In NO case should you be able
to remove bounds checking in @safe code.
It is. In fact, that's the very reason why DMD has
-noboundscheck in addition to -release.
I meant correct as in not wrong, not correct as in the
current state of the compiler :)
Otherwise, @safe is just another meaningless convention.
Walter?
-Steve
It's funny because just the other day I tried argue on Rust
mailing list why -noboundscheck flag should be added to the
Rust compiler. My argument didn't go down very well. But my
point was that someone at some point might have a genuine need
for that flag, and that having the option to compile the code
to an unsafe program doesn't make the language itself any less
safe.
@safe guarantees memory-safety given that any @trusted code
used doesn't break its promise and that you don't use the
-noboundscheck flag. That doesn't sound like a convention to
me.
No, the author of the @safe code expects bounds checking, it's
part of the requirements. To compile his code with it off is
like having a -compilergeneratedhash switch that overrides any
toHash functions with a compiler generated one. You are
changing the agreement between the compiler and the code.
Obviously if such or any other compiler flags exist, their
existence and behaviour has been specified in binding agreement
between the compiler and the source code, and thus, no breach of
contract has happened if such compiler flags were used.
