improvement request - enabling by-value-containers

[Simon Buerger]

On 09.12.2010 23:39, Jesse Phillips wrote:
> Simon Buerger Wrote:
>
>> 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.
>
> Why? You put row in there and said there was 5 of them.
>
> vec[] = row.dup;
> I believe that would be the correct syntax if you wanted to store 5 different vectors of the same content (Works for arrays).

No, that line would duplicate row once, and store that same copy in 
every element of vec.

>> I partially see your point, the constructor would be called in places
>> the programmer didnt expect, but actually, what's the problem with an
>> exception? They can always happen anyway (at least outOfMemory)
>
> I think there is even more too it. init is used during compile time so properties of the class/struct can be checked. I don't think exceptions are supported for CTFE.
>
>> letting "in" decide would be cleaner IMO, but anyway good to hear that
>> problem is recognized. Will look for the other thread.
>
> I'm not sure if the spec says in must be passed by reference, only that is how it is done. I'd think it'd be up to the compiler.

Other way around, "in" is currently passed by value, though the spec 
does not explicitly disallow by reference, so it might be implemented 
without even changing the spec.

>> You are right that default-const would be contrary to the rest of the
>> language, but when I think longer about this... the same default-const
>> should apply for all function parameter. They should be input, output
>> or inout. But the "mutable copy of the original" which is common in
>> C/C++/D/everything-alike, is actually pretty weird. (modifying
>> non-output parameters inside a function is considered bad style even
>> in C++ and Java). But well, that would be really a step too big for
>> D2... maybe I'll suggest it for D3 some day *g*
>
> I believe Bearophile has beat you too that. Think it is even in Bugzilla. I think it would only make sense to add it to D3 if it becomes common to mark functions parameters as in. But I agree it is easier to think, I want to modify this then it is to say I'm not modifying this so it should be in. Though currently I don't think there is a way to mark the current default behavior.

Well, it would be good style to add in/out to each and every parameter 
there is, but I dont do it myself either (except in 
container-implementations, where good style and the last bit of 
optimizer seems important)

Krox