On Thu, 10 Apr 2014 10:55:26 -0400, Tommi <[email protected]> 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
<[email protected]> 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. When I say @safe, I mean "I absolutely always want
bounds checks."
If you want to eliminate bounds checks, use @trusted.
-Steve
