improvement request - enabling by-value-containers

[Bruno Medeiros]

Sorry for the long delay in replying.

On 22/12/2010 12:04, Simon Buerger wrote:
> 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.
>

I don't understand this, it doesn't seem to make sense. You say you 
don't want the set to be "some mutable object", yet also say you "want 
it to be mutable". Does "it" refer to something else? I don't get it.

Assuming just this text: " 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. "
Then pass in some unmodifiable collection. Hard to suggest a better 
alternative without a concrete example.


>>> 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
Why is it not the way to go for D?
Why is "total math-like behavior is impossible" ?

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

Not the best comparison, since the by_reference_correct version could be 
improved to something like:
applyFill(a, set!int.empty) // if the last parameter is lazy
or
applyFill(a, { set!int.empty }) // otherwise, param is delegate instead


but in any case this is just a very specific example. What about the 
other cases where by value could would be more verbose than by 
reference? (particularly when you want to avoid needless copies)

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

The only way to truly solve this problem for you is to use by-value 
containers, and actually use them with value semantics all the time (ie, 
don't turn them into by-ref by passing pointers or other references to 
them) !

...Well, this does contradict a bit what I originally said that "how can 
anyone think this is a good idea? " But note that I was talking about 
within the context of C++. If you use by-value containers in the 
described above (with actually value semantics usage) you will be sooner 
or later incurring heavy performance costs such that it's no longer a 
good idea to be using C++ in the first place.

-- 
Bruno Medeiros - Software Engineer