On Wednesday, 7 November 2012 at 10:33:03 UTC, Timon Gehr wrote:
You are still missing that const in C++ is different from const
in D. Also, if the point is to have higher speed, why shouldn't
the function be allowed to use an rvalue as scratch space
without a _deep copy_ ?
const in C++ does not mean anything. It is just loosely
enforced interface documentation. const in D actually restricts
what the callee can do with the argument, in a transitive
fashion.
Also depending on how you think of it, the const ref in C++
logically it didn't make sense to pass a mutable rvalue; Say you
pass the number 3, you can't modify it logically (ie you can't
redefine PI afterall).
When my struct does not support any operations that are const,
and creating a mutable copy is not possible due to indirections?
I would simply continue to disallow that, since that would
mean that changes to the referenced rvalue would not be
visible for the caller (a temporary/literal is changed - how
could someone possibly want that?).
The change may well be visible...
class C{
int x;
}
struct W{
C c;
}
W createW(C c){ return W(c); }
void foo(ref W w){ w.c.x = 2; }
void main(){
C c = new C;
assert(c.x==0);
foo(createW(c));
assert(c.x==2);
}
So basically being named (or not) doesn't change the data, what
it is or how it's used, only how accessible it is.
There's some forms of techniques that don't seem to have any
value until you have a chance to think about it and use them;
Like scopes, overloading, referencing, Exceptions you can easily
do without them all (We have C afterall), but it isn't as much
fun or clean. Some features and uses thereof make more sense for
the back/private implementation rather than the public interface.
The reason I gave my 'divide' example is because a while back I
wrote a BitInt (in C like 10 years ago, and a bit buggy); The
divide function actually calculated the remainder as a side
effect, and using wrappers or writing them as separate portions
would actually be harder and slower than joined as it was.
