"Walter Bright" <[email protected]> wrote in message news:[email protected]... > > 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.
