improvement request - enabling by-value-containers

[Simon Buerger]

On 21.12.2010 18:45, Bruno Medeiros wrote:
> On 09/12/2010 21:55, Simon Buerger wrote:
>> 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.

Identity is wrong, because if I pass th set {1,2,3} to a function, I 
would like to pass exactly these three values, not some mutable 
object. This may imply that the function-parameter should be const, 
which is probably a good idea anyway. I want it to be mutable, I want 
to use "out"/"ref", the same way as with the simple builtin-types.

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

You might be right that modeling mathematics is not perfect, at least 
in C/C++/D/java. Though the functional-programming is fine with it, 
and it uses immutable data just as you suggested. But I'm aware that 
thats not the way to go for D.

Anyway, though total math-like behavior is impossible, but with
auto A = Set(1,2,3);
auto B = A;
B.add(42);
letting A and B have different contents is much closer to math, than 
letting both be equal. Though both is not perfect.

And for the "immutable data": Its not perfectly possible, but in many 
circumstances it is considered good style to use "const" and 
"assumeUnique" as much as possible. It helps optimizing, 
multi-threading and code-correctness. So it is a topic not only in 
functional programming but also in D.

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

Maybe you want to change that stuff later on, so static-length is no 
option. Following example might demonstrate the problem more clearly. 
It is intended to init a couple of sets to empty.

set!int[42] a;

version(by_reference_wrong):
a[] = set!int.empty;	// this does not work as intended

version(by_reference_correct):
foreach(ref x; a)
	x = set!int.empty;

version(by_value):
//nothing to be done, already everything empty

Obviously the by_value version is the cleanest. Furthermore, the first 
example demonstrates that by-reference does not work together with the 
slice-syntax (which is equivalent to the constructor-call in my 
original example). Replacing "set!int.empty" with "new set!int" doesnt 
change the situation, but make it sound only more weird in my ears: 
"new vector"? what was wrong with the old one? and I dont want "_an_ 
empty set", I want "_the_ empty set". Every empty set is equal, so 
there is only one.

Last but not least let me state: I do _not_ think, that 
value-containers will go into phobos/tango some day, that would to 
difficult in practice. I just want to state that there are certain 
reasons for it. (And originally this thread asked for some small 
changes in the language to make it possible, not the standard).

Krox

ps: I'll go on vacation now, see you next year, if there is still need 
for discussion. Merry christmas all :)