Andrei Alexandrescu wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
Jason House wrote:
I posted in the other thread how casting to immutable/shared can be
just as bad. A leaked reference prior to casting to immutable/shared
is in effect the same as casting away shared. No matter how you mix
thread local and shared, or mutable and immutable, you still have the
same undefined behavior
Not undefined, it's just that the compiler can't prove it's defined
behavior. Hence, such code would go into a trusted function.
Are we in agreement that @safe functions have bounds checking on
regardless of -release?
You're right from a theoretical perspective, but not from a practical
one. People ought to be able to flip on 'safe' without large
performance penalties.
If it came with inescapable large performance penalties, then it'll
get a bad rap and people will be reluctant to use it, defeating its
purpose.
This is a showstopper.
What kind of reputation do you think D would achieve if "safe" code has
buffer overrun attacks?
A function that wants to rely on hand-made verification in lieu of
bounds checks may go with @trusted. There is absolutely no way a @safe
function could allow buffer overruns in D, ever.
I agree if the flag is called "-release". But if the "disable bounds
checking" flag is renamed to -unsafe or similar, I can't see any impact
on reputation.
