On Saturday, 14 June 2014 at 00:40:06 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Sat, 14 Jun 2014 00:34:51 +0200
Timon Gehr via Digitalmars-d <[email protected]>
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 <[email protected]>
> 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,
and there are a number of places that the language requires an
init value
(like arrays), making types which don't have init values
problematic to use.
Overall, I think that adding @disable this() to the language
was a mistake.
Huh? Types with `@disable this()` still have an `init` value. All
it does is disallow instantiating the type without specifying an
initializer (e.g. a struct literal, a value returned from a
factory function, or `static opCall()`).
