improvement request - enabling by-value-containers

[Jonathan Schmidt-Dominé]

Hi!

Just about my experiences: When trying to hack some algorithms quickly in 
Ruby I made a lot of mistakes because I had to care about a .clone 
everywhere and because Array.new(5, []) does not work as expected (sorry, 
but Array.new(5) { return [] } is not nice). So in fact C++ made my life 
easier than the new, stylish, simple Ruby-programming-language, because of 
the great by-value-containers in the STL.

However, some reasons for by-value-containers:
*First of all you often have to deal with mutli-dimensional data-
structures, 
you map something to a map of lists of whatever and you want to manage 
suche 
data in a simple and generic way, simplification or extensions to the data-
structure should not force you to refactor all more or less generic code-
fragments. For example copying some entries around should not look 
different 
just because you added a dimension in your data-structure. But without 
proper value-semantics you are forced to do that, because at some point you 
will have to switch from by-value to by-reference because of limitations 
made somewhere.
*Another argument: It should be very simple (at least in C++ it is, I have 
never had problems with it, I just added the & here and there) to handle 
references to by-value-types, but wrapping by-reference-types into by-value-
types is really ugly, although it may be the right thing somewhere.
*By-value-containers support more generic code. A copy_if on a multi-
dimensional container should of course copy the element and not just copy 
some references, and it would be bad if the generic implementation would 
have to test if the type is by-reference, but a container supporting clone, 
eventually using clone, bothering if it is a deep clone etc. I just do not 
see a simple way to make such generic algorithms easy to implement (even 
with new language features) if by-value-types are not fully supported and 
not used for containers.
*Whether or not you think by-value-containers are good, a better 
alternative 
for in would be great for generic code. In C++ I can use something like 
parameter_type<T>::result choosing by-reference or by-value automatically, 
it is not very nice, but it is simply impossible with D, there are no 
reference-types, there are no ways to implement such decisions in the 
parameter-lists, and in normal code it is impossible more than ever. But 
imagine there would be a simple you could put in front of a variable or 
paramater declaration choosing by-ref/by-value automatically, lets say §, 
and of course it should be const and scope, so you would put a § before 
your 
parameters, because you may not know if type is big or not (there are 
sometimes big PODs, somebody may want to pass a FILE-object to a generic 
function or whatever), you would use a § an a read-only-foreach, and you 
would not have to bother about anything, when extracting a container-
element 
temporarily (pivot in quicksort or whatever, you may want to sort your 
PODs, 
by-value-containers, primitives, pointers, class-objects etc.), you would 
use a § and it would be perfect. This would allow the implementation of by-
value-containers (of course default-constructors are also required), but it 
would allow to write more generic high-quality code everywhere. In D3 this 
could even be the default for function-parameters, the C-compatible default-
behaviour is simply nonsense.

Regards

The User