D - Unsafe and doomed

[Walter Bright]

On 1/4/2014 3:04 PM, deadalnix wrote:
> On Saturday, 4 January 2014 at 22:06:13 UTC, Walter Bright wrote:
>> I don't really understand your point. Null is not that special.
>>
>> For example, you may want a constrained type:
>>
>> 1. a float guaranteed to be not NaN
>> 2. a code point guaranteed to be a valid code point
>> 3. a prime number guaranteed to be a prime number
>> 4. a path+filename guaranteed to be well-formed according to operating system
>> rules
>> 5. an SQL argument guaranteed to not contain an injection attack
>>
>> The list is endless. Why is null special?
>
> Because it is an instant crash,

Would things going on and a random thing happening randomly later be better?

> because it is not possible to make it safe
> without runtime check,

Wrapper types can handle this.

> because it is known to fool optimizer and cause really
> nasty bugs (typically, a pointer is dereferenced, so the optimizer assume it
> isn't null and remove null check after the dereference, and then the dereference
> is removed as it is dead.

I'd like to see a case where this is nasty. I can't think of one.


> a bugguy code that could have crashed will know behave
> in random ways).

Above it seems you were preferring it to fail in random ways rather than instant 
and obvious seg fault :-) For the record, I vastly prefer the instant seg fault.


> On the other hand, it is really easy to make all of this burden disappear at
> language level.

I've posted a NonNull wrapper here a couple of times. I think it is adequately 
addressable at the library level, with the bonus that the same technique will 
work for other constrained types.


> 2 should also be ensure by @safe .

@safe is for memory safety.


> 3, 4, 5 can easily be ensured by current type system.

By exactly the same technique as non-null can be. Non-null does not require a 
special language case.


> I'm not knowledgeable enough on floating point standard to express any opinion
> on 1.

It's the same issue.