Null references (oh no, not again!)
Nick Sabalausky
a at a.a
Wed Mar 4 11:41:56 PST 2009
"Walter Bright" <newshound1 at digitalmars.com> wrote in message
news:gomj88$1253$1 at digitalmars.com...
>
> I just find:
>
> unchecked
> {
> ... code ...
> }
>
> awfully ugly. I doubt it would be used where it would need to be. Global
> switches that change the behavior of the language are bad, bad ideas. It
> makes code unverifiable and hence untrustable.
That srikes me as a weak argument (partucularly since I just don't see the
ugliness). Maybe that could be somewhat ugly for very small sections of
code, but for those cases there is also this:
int x = unchecked(...expr...);
Plus, if you're not going to have a global switch for this sort of thing,
then being able to turn it on locally becomes that much more important.
As far as the SafeInt-style proposal, the problem I see with it is that the
need vs lack-of-need for overflow checks tends to be based more on what
you're doing with the variables rather than the actual variables themselves.
(Plus, weren't you just saying in the null/nonnull discussion that you
didn't want more variations on types?)
> I doubt it would be used where it would need to be.
It would certainly be better than nothing. And besides, I could say the same
about the SafeInt-style proposal.
> Global switches that change the behavior of the language are bad, bad
> ideas. It makes code unverifiable and hence untrustable.
Aren't you already doing that with things like bounds checking? I've been
under the impression that, when built with "-release", an out-of-bounds
access will result in undefined behavior, instead of an exception/assert,
just as in C.
More information about the Digitalmars-d
mailing list