On 5/18/2013 8:54 PM, deadalnix wrote:
On Sunday, 19 May 2013 at 01:20:31 UTC, Walter Bright wrote:
I understand that. But the rationale you gave for having a default constructor
was to be able to disable default construction.
RAII or construction based on template parameters.
I know what default constructors are used for in C++. That wasn't what I asked,
though. I asked for compelling rationale.
I know that some languages have a special syntax for non-null pointers. I
disliked this solution for D because non-nullable pointers are just one
instance of creating a type with a limited set of values. Why not go for a
general solution? Why not create a mechanism where a type can be defined that
can only consist of prime numbers, for example? Why not ranged integer types?
Actually most languages does the reverse. They have non nullable type, and
provide Nullable/Option/Maybe/whatever to allow for nullable type. It allow to
ensure that null don't pops up in unexpected places, and that null must be
handled when it is an option.
Can you list some of those languages?
The current solution is to rely on faith, and I remember someone talking about
that at DConf recently.
Rely on what faith?
Now that what other languages does is cleared, let's do some consideration on
null.
A pointer point on something. For instance, an int* point on an integer. null
doesn't point on a integer. Non nullable pointer aren't a restricted set of
values, as, by definition, null isn't a value that point to an int. That doesn't
stand either.
By definition? Pointer semantics are what we choose it to mean.
D already have thing like Nullable in the standard lib. Introducing Maybe is
also pretty easy. Adding NonNullable in addition to Nullable sound like
something is not quite right.
Nullable is something different - it exists to give a 'null' value to things
that don't have a null representation, like an int.
C#, for example, has a Nullable type constructor, but it still has object
references that can be null. C# has no standard way to produce a non-nullable
object reference.
There's no non-null wrapper in Java, either.
The benefit we get from null, ie having a default initialization for everything,
is moot if @disable this() is introduced, so it is questionable at this point
how useful it really is except as make up over current implementation
deficiencies.
It's not fundamentally different from other schemes to prevent any default
initialization.
Finally it has to be added that null cause holes in @safe in ways that are
difficult to impossible to solve.
I presume you are talking about objects bigger than 64k. It is a problem, and
we'll have to deal with it, but a rare one.
