ref?

[Andrei Alexandrescu]

dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>> Walter and I have been discussing what the regime of statically-sized
>> arrays should be. In short, the behavior that's most consistent with
>> everything else is to treat them as values.
>> This also brings the problems of e.g. containers - should they have
>> consistent value semantics (like in STL)
> 
> Oh God no!  I always thought the value semantics of STL containers were largely a
> kludge to work around the fact that C++ doesn't have garbage collection.  They
> make it easier to use RAII for memory management, since every object has a clear
> owner.  This leads to tons and tons of copying if code is written the obvious way,
> and lots of kludges to prevent it.

Well I never seemed to have a problem with it, quite the contrary in 
fact. Values are easier to reason about because they don't have aliasing 
and don't foster long-distance interdependencies.

>> or consistent reference
>> semantics (like in Java)?
> 
> Yes.  Largely to be consistent with builtin dynamic arrays and AAs, and for
> efficiency, to avoid hidden copying.

Today's dynamic arrays and AAs are really ranges. This becomes most (and 
most embarrassingly) visible when expanding a dynamic array with ~= 
comes into discussion.

> I consider the builtin static arrays to be
> just a niche performance hack anyhow, and hardly ever use them because they're too
> inflexible, so consistency with them isn't as important.  If you want to duplicate
> something before passing it to something else, attaching a simple .dup to the end
> as in foo(myArray.dup) works pretty darn well.  All the standard containers should
> simply have a .dup method, which works similarly to the builtin dynamic array .dup
> method.

Attaching a .dup doesn't always work that pretty darn well because 
sometimes you really want .deepdup without realizing it. The .dup 
thingie copies only one layer of the onion. To bring this more into 
perspective, threading with STM does necessitate guarantees of full, 
alias-free copies of entire graphs of objects.

So I guess I disagree with most of your post :o).


Andrei