On Friday, 5 October 2012 at 18:36:07 UTC, Simen Kjaeraas wrote:
Indeed. However, given both types, I would argue that
non-nullable by
default would go best with the D design guidelines - safe
before unsafe,
to be specific.
Clearly that would be the case, else we're tossing aside the
guidlines as they are written. References should be safe first
which means they must be non-nullable by default, but it also
should be possible to make references unsafe for those who
require unsafe abilities (this is also stated in the guidlines).
It is that sort of general set of guidlines that convinced me
into investing my time in D, and away from C++ which has the
opposing set of guidelines. I can do safe coding by default, and
also unsafe in the normally few places where required.
Of course, given the current state of D, retroactively fitting
non-nullable references/pointers by default is impossible,
unwanted,
and simply a bloody stupid idea.
Unfortunately, it is that sort of requirement that resulted in
C++ being not much better than C, but I have to agree that D2 has
to first solidify itself into a production capable state, this is
one of the biggest challenges it has right now.
However thinking ahead...
If D as a language is to evolve sensibly, it requires a means to
make breaking changes, otherwise it will remain stuck with less
than optimal design choices, and in some cases really bad ones.
So it seems we do not have a practical means to evolve, other
than making mediocre changes once every 8 years or so, as we saw
with the C++11 update. Do we really want that to happen with D?
This is a separate topic, but perhaps using this feature can help
get around the inability to evolve problem?
http://dlang.org/version.html
--rt
