improvement request - enabling by-value-containers

[Bruno Medeiros]

On 09/12/2010 21:55, Simon Buerger wrote:
> On 08.12.2010 23:45, Jonathan M Davis wrote:
>> On Wednesday, December 08, 2010 14:14:57 Simon Buerger wrote:
>>> For Every lib its a design descision if containers should be value- or
>>> reference-types. In C++ STL they are value-types (i.e. the
>>> copy-constructor does a real copy), while in tango and phobos the
>>> descision was to go for reference-types afaik, but I would like to be
>>> able to write value-types too, which isn't possible (in a really good
>>> way) currently. Following points would need some love (by-value
>>> containers are probably not the only area, where these could be useful)
>>
>> It's extremely rare in my experience that it makes any sense to copy a
>> container
>> on a regular basis. Having an easy means of creating a deep copy of a
>> container
>> or copying the elements from one container to another efficiently
>> would be good,
>> but having containers be value types is almost always a bad idea. It's
>> just not
>> a typical need to need to copy containers - certainly not enough to
>> have them be
>> copied just because you passed them to a function or returned them
>> from one. I
>> think that reference types for containers is very much the correct
>> decision.
>> There should be good ways to copy containers, but copying shouldn't be
>> the
>> default for much of anything in the way of containers.
>

I would go further than that actually, it seems to me that the idea of 
by-value containers is completely idiotic. I was *hesitant* to say this 
because it goes against conventional C++ "wisdom" (or rather, C++ 
mentality), and I'm just a random junior programmer on a web forum, and 
I am saying it in a somewhat inflammatory way... But frankly, I've been 
thinking about it for the last few days (the issue came up earlier, in 
the "Destructors, const structs, and opEquals" thread), and I could not 
change my mind. For the love of life, how can anyone think this is a 
good idea? I'm struggling to find even one use-case where it would make 
sense. (a non-subjective use-case at least)

>  From a pragmatic viewpoint you are right, copying containers is rare.
> But on the other hand, classes imply a kind of identity, so that a set
> is a different obejct then an other object with the very same elements.

Yeah, classes have identity, but they retain the concept of equality. 
So what's wrong with that? Equality comparisons would still work the 
same way as by-value containers.

> That feels wrong from an aesthetical or mathematical viewpoint.

Aesthetics are very subjective (I can say the exact same thing about the 
opposite case). As for a mathematical viewpoint, yes, it's not exactly 
the same, but first of all, it's not generally a good idea to strictly 
emulate mathematical semantics in programming languages. So to speak, 
mathematical "objects" are immutable, and they exist in a magical 
infinite space world without the notion of execution or side-effects. 
Trying to model those semantics in a programming language brings forth a 
host issues (most of them performance-related). But more important, even 
if you wanted to do that (to have it right from a mathematical 
viewpoint), mutable by-value containers are just as bad, you should use 
immutable data instead.

> Furthermore, if you have for example a vector of vectors,
>
> vector!int row = [1,2,3];
> auto vec = Vector!(Vector!int)(5, row);
>
> then vec should be 5 rows, and not 5 times the same row.
>

Then instead of "Vector" use a static-length vector type, don't use a 
container.

-- 
Bruno Medeiros - Software Engineer