On Sun, 19 May 2013 20:23:21 +0200, Walter Bright
<newshou...@digitalmars.com> wrote:
On 5/19/2013 5:02 AM, Simen Kjaeraas wrote:
By definition? Pointer semantics are what we choose it to mean.
Of course. But which definition is saner:
For many types, it is extremely useful to have some sort of "invalid"
value for it. null fills that role nicely for pointers, just as nan does
for floating point types, and 0xFF does for UTF-8.
There's not anything insane about it. The Nullable type constructor even
exists in order to provide such an invalid state for types (like int)
which normally do not have one.
Yes, I do understand there's a role for pointers which cannot hold the
invalid value.
I contend that not only is there a role for them, but that most pointers
should never be null. Here's two questions that convinced me:
1. How many functions that take a pointer or class reference make sense
to call with null in that pointer/reference?
2. If pointers were non-nullable by default, how often would you need to
reach for the nullable one?
I argued in another post that nullable by default is analogous to using a
string instead of an int - any number representable in an int is
representable in a string, *and* the string can represent error states.
But if you only want valid ints, there's no reason to use a string.
--
Simen
