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.
