Error about @disabled constructor when there is a custom one

Simen Kjaeraas simen.kjaras at gmail.com
Wed Jan 23 02:27:13 PST 2013


On 2013-43-23 09:01, deadalnix <deadalnix at gmail.com> wrote:

> On Wednesday, 23 January 2013 at 08:00:05 UTC, Simen Kjaeraas wrote:
>> On 2013-45-23 04:01, deadalnix <deadalnix at gmail.com> wrote:
>>
>>> On Tuesday, 22 January 2013 at 19:07:56 UTC, Simen Kjaeraas wrote:
>>
>>>> One could argue that the compiler should choose the other  
>>>> constructor, and
>>>> even that having default constructors is reasonable. However, D has  
>>>> gone
>>>> the route of not having default constructors for structs. Instead,
>>>> structs are defined to be trivially constructible from T.init.
>>>>
>>>
>>> Which incompatible with the desire of a NonNull construct.
>>
>> Really? It's not like you cannot @disable T.init. Please show how this  
>> is
>> a problem for NonNull!T.
>>
>
> Easy :
>
> NonNull!T bar; // bar is null

Patently false. @disable this() makes this fail with "initializer required
for type".


> NonNull!T[] barArray;
> barArray.length = 5; // barArray contains null elements.

This is a known bug in the implementation of @disable this().


> NonNull!T bar = something;
> foo(move(bar));
> bar; // bar is null \o/

Except it isn't.


-- 
Simen


More information about the Digitalmars-d mailing list