"Steven Schveighoffer" wrote in message
news:op.xd5lomc1eav7ka@stevens-macbook-pro.local...
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"
Trying to prevent developer stupidity is a lost cause.
Bounds checks are on by default. They are even on when you ask for
'fast-over-safe' aka -release. They get turned off when you explicitly ask
for it.
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.
Something like (() @trusted => arr.ptr[index]) should do the trick.
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.
@trusted delegates get you 99.99% of the way there.
