Null references (oh no, not again!)

[Nick Sabalausky]

"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:gomoc6$1aoa$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> 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?)
>
> This would be the user's choice. Those that don't care for it, needn't use 
> it. That's the advantage of the SafeInt class.
>

First, with the C#-style of handling overflows, the user can also choose to 
not use it if they don't need it. Second, this doesn't address the original 
problem with SafeInt that I pointed out. Third, those who do choose to use 
SafeInt are still back to the issue of two different versions of a type (Not 
that I have a big problem with this point, but it just seems to conflict 
with the similar issue you had with null/nonnull).

>>> 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.
>
> In Java, you can rely on bounds checking to always be on, so you could, 
> for example:
>
> try
> {
>    for (int i = 0; i; i++)
>        array[i] = ...
> }
> catch (ArrayBoundsException a)
> {
> }
>
> which is perfectly legitimate code in Java. It is dead wrong in D, because 
> the language behavior is defined to not necessarily throw such exceptions.
>

Isn't that what I was just saying? D's behavior on such code is, depending 
how you look at it, either undefined, or dependant upon the "-release" / 
"-debug" compile switches.

> With overflow, there are legitimate uses of overflow arithmetic. You'd be 
> hard pressed to make a statement like "overflow arithmetic is illegal in 
> D" and have a useful systems programming language.

I don't think anyone is suggesting that. Sometimes you want overflow 
allowed, sometimes you want it disallowed (and sometimes, for better or 
worse, you don't give a rat's ass). We just want to be able to make that 
choice when we need to make it. Ie, "Overflow behavior is controllable in 
D".