improvement request - enabling by-value-containers

[Andrei Alexandrescu]

On 12/14/10 3:29 PM, Jonathan Schmidt-Dominé wrote:
> 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.

Thanks for sharing.

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

I think this argument goes exactly the other way. C++ containers have 
terrible compositional behavior. Using vector<vector<T> > or 
vector<map<T> > in C++98 is suicide. C++0x fixes that by means of 
introducing rvalue references, but reference semantics obviate all that.

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

"here and there" is more like "every time I define a function". I mean 
that's a lot, no?

Wrapping could work either way, and after thinking about it a lot I have 
difficulty decreeing one is considerably easier/simpler than the other.

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

copy_if on a multidimensional container should not naively copy entire 
hyperplanes. More generally, I think that whenever an arbitrarily large 
object is to be copied, that should be explicit instead of implicit. A 
lot of focus in C++ is dedicated to making sure you don't copy the wrong 
thing.

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

It would be great to have D just obviate the necessity of 
parameter_type<T>::result in the first place, which is what auto ref is 
meant for (it's §).

> The User

s/The/A/ I guess ;o).

One issue that I noticed about myself and other people coming to D from 
C++ is that we expect to bring with us, along with the many things that 
make C++ great, the baggage of common worries, misgivings, and just rote 
work that we got used to.


Andrei