Null pointer dereferencing in D

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Sat Jun 14 06:23:59 PDT 2014


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 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,

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.
>...





More information about the Digitalmars-d mailing list