On 09/07/2011 07:18 AM, Marijn Haverbeke wrote:
While this is attractive from the perspective of having the
right defaults, it also makes the semantics of the code at a glance more
subtle.
The semantics are not effected at all -- both with 'structurally
immutable' and with immediate values, it is not observable whether the
parameter was passed by value or by reference.
Yeah, I'm more concerned about mutable structural values (e.g. records
with one or more mutable fields). In that case it does matter
semantically whether the parameter is passed by value or by alias.
There aren't many languages I know of that have mutable value types -- I
only know of C, C++, and C# (though I wouldn't be surprised if Fortran,
Pascal, COBOL, or Ada had them too). To my knowledge, in all of them,
passing a value type as a parameter results in a copy. In C++, where
mutable structural value types are commonest, this often gets criticized
for leading to subtle bugs, so I agree we need a solution there. It may
well be a question of having the default mode be alias.
To be clear, I'm not opposed to your proposal. I just have two concerns:
(a) that we are getting dangerously close to violating programmers'
assumptions regarding what a mutable structural value type means, and
(b) that we are making the ABI more difficult to predict. These concerns
are why I advanced the suggestion earlier: make no sigil mean "immutable
alias semantics, but the compiler may choose to promote to value if the
value is immutable and small", but have an explicit copy sigil mean
"always copy".
Follow-up thought: If we had an explicit copy sigil, that might mean we
could use this function:
fn copy<T>(*x : T) -> T { x }
as our copy operator...
Patrick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
