On Fri, 11 Apr 2014 08:35:07 -0400, Daniel Murphy
<yebbliesnos...@gmail.com> wrote:
"Steven Schveighoffer" wrote in message
news:op.xd3vzecweav7ka@stevens-macbook-pro.local...
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
-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 have code that would ever fail a bounds check, that is a program
error, similar to code that may fail an assertion.
And like assertions, if you would rather the code was as fast as
possible instead of as safe as possible you can use a compiler switch to
disable bound checks.
The usual switch to do stuff like this is '-release', but because @safe
functions should still have the 'no memory corruption' even in release
mode, disabling those bounds checks was moved into another compiler
switch.
If you want to eliminate bounds checks, use @trusted.
No, @trusted means "don't check my code" while @safe + noboundschecks
means (mostly) "only check my code at compile-time".
Here is the horror scenario I envision:
1. Company has 100kLOC project, which is marked as @safe (I can dream,
can't I?)
2. They find that performance is lacking, maybe compared to a competitor's
C++ based code.
3. They try compiling with -noboundscheck, get a large performance boost.
It really only makes a difference in one function (the inner loop one).
4. They pat themselves on the back, and release with the new flag,
destroying all bounds checks, even bounds checks in library template code
that they didn't write or scrutinize.
5. Buffer overflow attacks abound.
6. D @safe is labeled a "joke"
But there is a cost, even to labeling the "one inner" function @trusted.
Perhaps that function is extremely long and complex. There should be a way
to say, "I still want all the @safety checks, except for this one critical
array access, I have manually guaranteed the bounds". We don't have
anything like that. All other safety checks are really static, this is the
only runtime penalty for safety.
The blunt flag approach is scary. @trusted is better, in that you can
focus on one function at a time. But I think we need something more
precise. Perhaps you should be able to have @trusted scopes, or @trusted
expressions.
-Steve
