On Thu, 10 Apr 2014 18:54:57 -0400, Martin Krejcirik <[email protected]>
wrote:
On 10.4.2014 19:12, Steven Schveighoffer wrote:
void foo(T)(T[] x) @safe
{
x[5] = 3;
}
Is this common practice ? I'd wouldn't call it a safe design.
No, this isn't common practice. It's a demonstration of how @safe code can
become un-@safe when compiled independent of the original author. In
reality, nobody should rely on a bounds check to catch out of bounds
conditions (I think it's an Error anyway -- a non-recoverable situation).
But memory bugs in safe code should be caught, at compile time if
possible, at runtime if not.
There
should be a length check or version check:
version(D_NoBoundsChecks) static assert(0, "bounds checking required");
But I get your point, I have always thought of bounds checking like an
optional safety net, you think of it like a required feature.
It is a safety net, but not optional for @safe code. The promise of @safe
is that you CANNOT have a memory corruption error. To break the promise
without the knowledge of the code is an incorrect plan, IMO. When you
write @safe, it means "this code is memory safe, even if it has bugs."
Perhaps Andrei and Walter feel differently. I don't know.
-Steve
