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