On 06/14/2014 02:39 AM, Jonathan M Davis via Digitalmars-d wrote:
On Sat, 14 Jun 2014 00:34:51 +0200
Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
On 06/13/2014 11:45 PM, Jonathan M Davis via Digitalmars-d wrote:
On Fri, 13 Jun 2014 21:23:00 +0000
deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
The approach consisting in having non nullable pointers/reference
by default is the one that is gaining traction and for good
reasons.
That interacts _really_ badly with D's approach of requiring init values
for all types. We have enough problems with @disable this() as it is.
- Jonathan M Davis
@disable this() and nested structs etc. Trying to require init values
for everything isn't an extraordinarily good idea. It roughly extends
'nullable by default' to all _structs_ with non-trivial invariants.
True, some types become problematic when you have to have an init value (like
a NonNullable struct to make nullable pointers non-nullable), but generic code
is way more of a pain to write when you can't rely on an init value existing,
Examples?
and there are a number of places that the language requires an init value
(like arrays),
Just use std.array.array.
making types which don't have init values problematic to use.
The solution is to have explicit nullable types, not to force a default
value on every type.
Overall, I think that adding @disable this() to the language was a mistake.
...
