null [re: spec#]

Simen kjaeraas simen.kjaras at gmail.com
Mon Nov 8 04:08:10 PST 2010


Denis Koroskin <2korden at gmail.com> wrote:

> On Mon, 08 Nov 2010 12:08:01 +0300, Simen kjaeraas  
> <simen.kjaras at gmail.com> wrote:
>
>> Eric Poggel <dnewsgroup2 at yage3d.net> wrote:
>>
>>> On 11/6/2010 6:50 AM, bearophile wrote:
>>>> foobar:
>>>>
>>>>> Any type can be wrapped by an OPTION type. trying to do the converse  
>>>>> of this is impractical and is bad design.
>>>>
>>>> Discussing this is a waste of time now, this part of the D language  
>>>> will probably never change.
>>>> This is why other people and me are proposition something different.
>>>>
>>>> Bye,
>>>> bearophile
>>>
>>> I still live in D1 land, so forgive me if I'm out of the loop--but  
>>> what keeps this from being implemented at the library level as  
>>> templated type:  NotNull!(T) ?  If there are limitations, maybe these  
>>> areas of the language can be improved to get us there?
>>
>> NotNull!T needs to have its default constructor disabled. That is the #1
>> blocker. There are other problems, mostly related to this - classes and
>> structs with NotNull!T fields must define a constructor, and for structs
>> that means the default destructor either needs to be possible to define
>> or possible to disable. Arrays of NotNull!T may not be resized to a
>> greater length, as that would require calling the default constructor of
>> NotNull!T.
>>
>> I think that's it.
>>
>
> Not exactly disabled. The following should work:
>
> class Foo
> {
>      this() {
>          bar = new Object();
>      }
>
>      NonNull!(Object) bar; // fine here
> }
>
> while the following shouldn't:
>
> NonNull!(Object) bar; // error here
> bar = new Object();

I belive you have misunderstood me. The NonNull struct would need to have
its default constructor disabled. Then, extra logic would need to be added
to class and struct constructors to ensure NonNull fields have their
constructors called.

Context-sensitive constructor disabling is a theoretical possibility, but
seems to me to conflict with D's other goals.

-- 
Simen


More information about the Digitalmars-d mailing list