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
