[phobos] Fwd: Re: Ruling out arbitrary cost copy construction?

[SHOO]

(2010/10/31 12:57), Andrei Alexandrescu wrote:
> I am highly interested in the opinion of Phobos contributors in the
> matter of copy construction (just posted the message below).
>
> Andrei
>
> -------- Original Message --------
> Subject: Re: Ruling out arbitrary cost copy construction?
> Date: Sat, 30 Oct 2010 22:56:24 -0500
> From: Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>
> Newsgroups: digitalmars.D
>
> On 10/30/2010 09:40 PM, Michel Fortin wrote:
>> On 2010-10-30 20:49:38 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> said:
>>
>>> On 10/30/10 2:24 CDT, Don wrote:
>>>> At the moment, I think it's impossible.
>>>> Has anyone succesfully implemented refcounting in D? As long as bug
>>>> 3516
>>>> (Destructor not called on temporaries) remains open, it doesn't seem to
>>>> be possible.
>>>> Is that the only blocker, or are there others?
>>>
>>> I managed to define and use RefCounted in Phobos. File also uses
>>> hand-made reference counting. I think RefCounted is a pretty good
>>> abstraction (unless it hits the bug you mentioned.)
>>
>> I like the idea of RefCounted as a way to automatically make things
>> reference counted.
>
> Unfortunately it's only a semi-automated mechanism.
>
>> But like File and many similar ref-counted structs, it has this race
>> condition (bug 4624) when stored inside the GC heap. Currently, most of
>> Phobos's ref-counted structs are race-free only when they reside on the
>> stack or if your program has only one thread (because the GC doesn't
>> spawn threads if I'm correct).
>>
>> It's a little sad that the language doesn't prevent races in destructors
>> (bug 4621).
>
> I hope we're able to solve these implementation issues that can be seen
> as independent from the decision at hand.
>
> Walter and I discussed the matter again today and we're on the brink of
> deciding that cheap copy construction is to be assumed. This simplifies
> the language and the library a great deal, and makes it perfectly good
> for 95% of the cases. For a minority of types, code would need to go
> through extra hoops (e.g. COW, refcounting) to be compliant.
>
> I'm looking for more feedback from the larger D community. This is a
> very important decision that marks one of the largest departures from
> the C++ style. Taking the wrong turn here could alienate many
> programmers coming from C++.
>
> So, everybody - this is really the time to speak up or forever be silent.
>
>
> Andrei

Another viewpoint.

Is SealedRange really appropriate?

All these are caused by the same problem:
- http://ideone.com/x1Zus
- http://ideone.com/iM18Q
- http://ideone.com/TTin3
- http://ideone.com/x4b0o

We should consider that we grope the common solution for these problems.
It is the method that block the access to reference data of which 
instance was deleted.