On 29/09/2011 4:07 PM, Patrick Walton wrote:
Now that every parameter is passed by reference, our ABI is no longer
compatible with C. Passing a struct by value is not the same as passing
it by immutable alias in C.
This is a severe problem, and my first instinct is to propose bringing
back & for it. We could bring the old meaning of & back just for native
calls, but that seems inconsistent.
& is already accepted there; it means "mutable reference" in rust abi.
I think this is probably less of a worry than you're seeing; the "new"
rust abi is "probably by reference, but by value in some cases". It only
has the freedom to choose when it's unobservable to safe code anyways
(when it's an immutable value). So the values are "effectively" the same
as passed-by-value as far as callee is concerned. That's why marijn
could make the change without breaking everything, after all :)
I think it's fine to have C abi say the same thing:
- un-adorned means "effectively by-value" (in C-abi, always!),
even though in many cases rust-abi will do this by-ref, only
in ways that are unobservable in safe code.
- adorned means "observably by-reference, mutable". This is
worth expressing in the signature anyways, since we can't
control what C will do with a pointer -- it might write through
it -- we might as well tell the alias checker we're forming a
mutable pointer here.
It does mean you have to re-add & to a lot of C-abi function signatures
that had the & removed during the recent abi shift. To "properly
document" that they are taking "mutable references".
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
