For Every lib its a design descision if containers should be value- or
reference-types. In C++ STL they are value-types (i.e. the
copy-constructor does a real copy), while in tango and phobos the
descision was to go for reference-types afaik, but I would like to be
able to write value-types too, which isn't possible (in a really good
way) currently. Following points would need some love (by-value
containers are probably not the only area, where these could be useful)
(1) Allow default-constructors for structs
I don't see a reason, why "this(int foo)" is allowed, but "this()" is
not. There might be some useful non-trivial init to do for complex
structs.
(2) const parameters by reference
If a parameter to a function is read-only, the right notion depends on
the type of that parameter. I.e. "in" for simple stuff like ints, and
"ref const" for big structures. Using "in" for big data implies a
whole copy, even though it's constant, and using "ref const" for
simple types is a useless indirection. This is a problem for generic
code, when the type is templated, because there is now way to switch
between "in" and "ref const" with compile-time-reflection.
Solution one: make "ref" a real type-constructor, so you could do the
following (this is possible in C++):
static if(is(T == struct))
alias ref const T const_type;
else
alias const scope T const_type;
// "const scope" is (currently) equivalent to "in"
void foo(const_type x)
Solution two: let "in" decide wheather to pass by reference or value,
depending on the type. Probably the better solution cause the
programmer dont need to care of the descision himself anymore.
(3) make foreach parameters constant
when you do "foreach(x;a)" the x value gets copied in each iteration,
once again, that matters for big types especially when you have a
copy-constructor. Current work-around is prepending "ref": nothing
gets copied, but the compiler wont know it is meant to be read-only.
Solution: either allow "ref const" or "in" in foreach. Or you could
even make x default to constant if not stated as "ref" explicitly.
Last alternative seems logical to me, but it may break existing code.
Comments welcome,
Krox
