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