On Oct 30, 2010, at 8:57 PM, 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.

Bug 4621 is tricky.  The appropriate fix is probably to have per-thread heaps, at least for data with finalizers.  It's a good direction to head anyway, so "stop the world" collections only occur when a shared allocation needs memory.

Hm... an alternative to per-thread heaps would be finalizer context info that indicates the owner thread for local data.  It's skewing storage use towards the common case, but would be easier to implement.

On Nov 1, 2010, at 8:58 AM, Steve Schveighoffer wrote:

> Ref counting still has to be thread aware because anything allocated on the heap can be destroyed in any thread, even if the type is not shared.  I think that is Michel's point.  Even if you don't store the reference types on the heap, something that contains the reference could be stored on the heap (think of a File member of a class).
> 
> -Steve
> 
> From: David Simcha <dsimcha at gmail.com>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Sent: Mon, November 1, 2010 11:33:19 AM
> Subject: Re: [phobos] Fwd: Re: Ruling out arbitrary cost copy construction?
> 
> Sounds reasonable iff we assume that ref counted stuff will never be shared across threads, which we seem to be assuming anyhow.
> 
> On Mon, Nov 1, 2010 at 12:21 AM, Andrei Alexandrescu <andrei at erdani.com> wrote:
> Alright, then how do we solve refcounting of constant objects (see Michel Fortin's question)? My solution involves casting away const and keeping immutability information at runtime. Is that acceptable?
> 
> Andrei
> 
> 
> On 10/31/10 5:32 PM, Shin Fujishiro wrote:
> I think cheap copy construction is must.  Since any accesses to sealed
> range elements involve copy construction.
> 
> I read older discussions and found that they mostly focused on swap and moveX.  But the problem lies not only in the swap operation.  It's everywhere and move doesn't help.
> 
> Note that *every* access to an element of sealed range involves a copy construction.  When sorting a sealed range of BigInts (Array!BigInt), even an innocent comparison creates two BigInt copies:
> 
>     if (!less(r[i], r[p]))  // Creates two temporary copies.
> 
> I think these copies can't be elided since original objects exist in a container at the same time.  Still the compared elements could be moved out and then assigned back, but that's terribly awkward.
> 
> We mostly don't want to move out elements - just want to read them. Sealed ranges are inherently copy intensive, so if you will put forward the concept, copy cost of elements must be assumed to be cheap IMO.
> 
> 
> Shin
> 
> Andrei Alexandrescu<andrei at erdani.com>  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
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

The trick is that finalizers are executed after the app threads are restarted, because running them beforehand can result in a deadlock.

On Nov 1, 2010, at 9:30 AM, David Simcha wrote:

> Can someone please fill me in?  Despite Michael Fortin's repeated attempts to explain it, I still don't understand how the status quo could generate a race condition under reasonable, real-world scenarios.  As I understand it (please correct whatever reasoning is wrong):
> 
> 1.  Incrementing/decrementing a size_t is atomic (i.e. has no intermediate state) on x86 and probably just about any other arch.  It is not, however, guaranteed sequentially consistent unless you use the lock instruction.
> 
> 2.  Stopping the world to do GC acts as an implicit fence.  If it didn't, then GC would be horribly broken.  This means that all refcount increments/decrements that happened in the owner thread should be visible to the collecting thread upon starting a collection.
> 
> 3.  You'd need some kind of fence (explicit or implicit) on terminating GC anyhow, to make data structures updated by the GC thread visible to all threads, thus making any increment/decrement of the reference count field done in the GC thread visible to all threads.
> 
> On Mon, Nov 1, 2010 at 12:17 PM, Andrei Alexandrescu <andrei at erdani.com> wrote:
> On 11/1/10 10:59 AM, Michel Fortin wrote:
> Le 2010-11-01 ? 0:21, Andrei Alexandrescu a ?crit :
> 
> Alright, then how do we solve refcounting of constant objects (see Michel Fortin's question)? My solution involves casting away const and keeping immutability information at runtime. Is that acceptable?
> 
> I don't see a big problem in bypassing const. But const objects might be immutable, and immutable objects are implicitly shared. So for immutable objects you'll need to use atomic increment/decrement on the reference counter; is this why you want to keep track of immutability at runtime?
> 
> I keep immutability info during runtime to avoid trying to write to immutable data.
> 
> I'm not sure about what to do for the GC affecting the reference count. It does look like we need to use atomic refcounting, which is a major setback for the entire approach.
> 
> In brief, if we want to go with cheap copy construction, we don't currently have a solution.
> 
> 
> Andrei
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On Nov 1, 2010, at 10:49 AM, David Simcha wrote:

> 
> 
> On Mon, Nov 1, 2010 at 1:39 PM, Michel Fortin <michel.fortin at michelf.com> wrote:
> 
> Is "i++" really atomic when i is a size_t? I though it was a read-modify-write operation. The read might be atomic, the write might be atomic, but the whole isn't. And in addition to atomicity, it needs to be sequentially consistent unless we change the GC to keep threads frozen while calling the destructors.
> 
> 
> In theory it could be read-modify-write because you never know if some incredibly stupid compiler will do something like:
> 
> mov EAX, [someAddress];
> inc EAX;
> mov [someAddress], EAX;
> 
> instead of just:
> 
> inc [someAddress];
> 
> However, I'm pretty sure the second form is atomic, and even if it's not formally guaranteed, any reasonable compiler would use the single inc instruction form.

The second form is only atomic when preceded by a LOCK modifier.  It's still done in the CPU as a RMW operation.

Yea, I tried it out, and I stand corrected.

On Tue, Nov 2, 2010 at 10:20 AM, Sean Kelly <sean at invisibleduck.org> wrote:

> On Nov 1, 2010, at 10:49 AM, David Simcha wrote:
>
> >
> >
> > On Mon, Nov 1, 2010 at 1:39 PM, Michel Fortin <michel.fortin at michelf.com>
> wrote:
> >
> > Is "i++" really atomic when i is a size_t? I though it was a
> read-modify-write operation. The read might be atomic, the write might be atomic, but the whole isn't. And in addition to atomicity, it needs to be sequentially consistent unless we change the GC to keep threads frozen while calling the destructors.
> >
> >
> > In theory it could be read-modify-write because you never know if some
> incredibly stupid compiler will do something like:
> >
> > mov EAX, [someAddress];
> > inc EAX;
> > mov [someAddress], EAX;
> >
> > instead of just:
> >
> > inc [someAddress];
> >
> > However, I'm pretty sure the second form is atomic, and even if it's not
> formally guaranteed, any reasonable compiler would use the single inc instruction form.
>
> The second form is only atomic when preceded by a LOCK modifier.  It's still done in the CPU as a RMW operation.
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101102/b2af2ed0/attachment.html>

(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.

Le 2010-11-02 ? 13:05, SHOO a ?crit :

> (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.

In first and second examples, you're taking the address of a local variable. This is forbidden in @safe code, so I consider this already solved.

In the third example, you're coping the sealed range into "r", then "ary" goes out of scope and delete the memory block while keeping a sealed range pointing to it. My take is that the implementation of Array is wrong: it should do *something* to either 1) prevent the sealed range from accessing the memory block, or 2) keep the memory block alive as long as a sealed range exists. Note that you can't write such an Array in @safe mode, and not using in @safe mode assumes you know what you're doing when it comes to handling memory. So I don't see that as a problem.

As for fourth example, it uses scope classes, which will be deprecated in D2.

Also take note that in second and third examples, the struct destructor is dangerous because it calls delete on a GC-allocated array "T[] a". As a general rule, you shouldn't access GC-allocated memory inside a destructor, this includes deleting it. That's because if you ever use this Array struct somewhere on the heap (like in a class), the GC could collect both the struct and the "T[] a" array at the same time, in whatever order, and you would calling the array's destructor twice (once by the GC + once in Array's destructor). But don't worry, you're not alone doing this mistake; I believe there is two instances of this in Phobos.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

All of these have nothing to do with sealed ranges.  They have to do with data lifetime.  If you destroy data and then try to access it, you will have problems with or without sealed ranges.  In addition, only one instance you show has a sealed range in it.  The rest either don't have ranges or are not sealed.

Having a sealed range does not necessarily mean that the user cannot shoot themselves in the foot and delete the data while still maintaining references to it.  This problem is mostly solved by having the data or at least the pointer to the data on the heap, destroyed by the GC when no longer needed.

Even then, this does not rule out the user calling clear on the pointer.

SealedRange is not a magic bullet for memory issues, and all these issues exist with or without sealed ranges or expensive copy construction.

What SealedRange *does* do is allow the container to have complete control over the storage for the data.  This means it can:

a) intercept all accesses to the memory, including writes and reads. b) use abstracted allocation schemes.

-Steve



----- Original Message ----
> From: SHOO <zan77137 at nifty.com>
> 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.
> _______________________________________________
> phobos mailing  list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
> 

On Tue, Nov 2, 2010 at 8:08 PM, Steve Schveighoffer <schveiguy at yahoo.com>wrote:

> All of these have nothing to do with sealed ranges.  They have to do with
> data
> lifetime.  If you destroy data and then try to access it, you will have
> problems
> with or without sealed ranges.  In addition, only one instance you show has
> a
> sealed range in it.  The rest either don't have ranges or are not sealed.
>
> Having a sealed range does not necessarily mean that the user cannot shoot
> themselves in the foot and delete the data while still maintaining
> references to
> it.  This problem is mostly solved by having the data or at least the
> pointer to
> the data on the heap, destroyed by the GC when no longer needed.
>
> Even then, this does not rule out the user calling clear on the pointer.
>
> SealedRange is not a magic bullet for memory issues, and all these issues
> exist
> with or without sealed ranges or expensive copy construction.
>
> What SealedRange *does* do is allow the container to have complete control
> over
> the storage for the data.  This means it can:
>
> a) intercept all accesses to the memory, including writes and reads. b) use abstracted allocation schemes.
>
> -Steve
>
>
>
> ----- Original Message ----
> > From: SHOO <zan77137 at nifty.com>
> > 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.
> > _______________________________________________
> > phobos mailing  list
> > phobos at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/phobos
> >
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101103/52a0b239/attachment.html>

 These notes on copy-constructible Qt types may be useful for the
discussion:

1. 1/5 (approx. 100 classes) of all classes in core, gui, network, webkit, svg and opengl packages define public copy-constructors.

A half of those are in reference-counted COW types (approx. 50 classes). The remaining 50 classes are reference-counted types without COW, types with allocating copy-constructors and types with trivial non-allocating constructors.

Most of the types with allocating copy-constructors I would probably implemented as classes in D. Polymorphic types like QListWidgetItem that provide the copy-constructor only for clone() reimplementation should definitely be classes in D.

The conclusion I tend to draw is that expensive copy-constructors can be avoided in most applications.

2. Reference counters are atomic using interlocked integer operations. There have been a couple of complaints about performance [ http://www.gotw.ca/publications/optimizations.htm] but those complaints seem ungrounded [ http://labs.qt.nokia.com/2006/10/16/atomic-reference-counting-is-it-worth-it-2 ].

3. If a type exposes data by reference, proxy objects are used to avoid unnecessary copying. For example, QString::operator[](int) returns an instance of Q?harRef, not QChar&. The shared data is copied only if the QCharRef instance is modified.

On Sun, Oct 31, 2010 at 5:57 AM, Andrei Alexandrescu <andrei at erdani.com>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
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101103/c4c29638/attachment.html>