T.init and @disable this

deadalnix deadalnix at gmail.com
Thu Oct 11 10:46:42 PDT 2012


Le 06/10/2012 15:21, Andrei Alexandrescu a écrit :
> On 10/6/12 4:06 AM, kenji hara wrote:
>> 2012/10/6 Jonathan M Davis<jmdavisProg at gmx.com>:
>>> On Saturday, October 06, 2012 16:27:30 kenji hara wrote:
>>>> 2012/10/6 Jonathan M Davis<jmdavisProg at gmx.com>:
>>>>> Regardless, we need to better sort out how disabling init works. It
>>>>> was my
>>>>> understanding that the correct way to do it was to do
>>>>>
>>>>> @disable this();
>>>>>
>>>>> but apparently that's in dispute (at least, Kenji doesn't seem to
>>>>> think
>>>>> that that's supposed to disable the init property), and it doesn't
>>>>> actually work.
>>>> My argue is simple: If your argument is proper behavior, you never
>>>> move NonNull object.
>>>
>>> What does disabling init have to do with moving? If you're moving an
>>> object,
>>> it already exists, so it doesn't need to be default initialized.
>>
>> Oh, sorry. I've talked about std.algorithm.move, didn't about proper
>> move in language semantics.
>
> I understand. Clearly we have a problem here, and it's tricky (C++
> dedicates a fair amount of machinery to it).
>
> I hope we find a simpler solution that disallowing 'T x;' but requiring
> 'T x = T.init;' for noncopyable objects. It's subtle and difficult to be
> explained and accepted by newcomers.
>

I think the compiler should prevent anything using a moved object with 
@disable this(); before it has been reinitialized.

The compiler will be able to do so if it is able to do it for the first 
initialization. This isn't more complicated.

It require language support, but no more than what is planned to be 
implemented anyway.


More information about the Digitalmars-d mailing list