Null pointer dereferencing in D
via Digitalmars-d
digitalmars-d at puremagic.com
Sat Jun 14 03:15:47 PDT 2014
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 <digitalmars-d at 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 at 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,
> 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()`).
More information about the Digitalmars-d
mailing list