Ahh, I guess I missed that rvalues of "moved" types are also moved when
used as parameters. Yes, that throws a wrench into my reasoning.
But this sucks! 95% of the time I don't want a function to take ownership
of it's arguments. I understand that this was done for consistency with
local assi
Patrick Walton wrote:
This is already done. The Rust ABI specifies that when large
structures are passed by move, a pointer is implicitly passed instead.
As an aside, I've been thinking that we can optimize the trans code
further for non-drop types that are located in immutable variables whic
On 4/4/13 3:05 PM, Vadim wrote:
What's so confusing about this? I agree that parameter modes had too
many options to think about, but this should be mostly transparent to
the user.Perhaps to the programmer semantics should stay the same as
if parameter was truly passed by value (i.e. no de-r
What's so confusing about this? I agree that parameter modes had too many
options to think about, but this should be mostly transparent to the
user.Perhaps to the programmer semantics should stay the same as if
parameter was truly passed by value (i.e. no de-referencing needed). The
differen
On 4/4/13 2:20 PM, Vadim wrote:
So I see all those borrow '&' sigils littering almost every function
declaration in Rust source, and I think that this is major contributor
to eye-soreness Rust syntax causes. Since '&' is so popular, couldn't
Rust just make it a default?
For instance, what if t
So I see all those borrow '&' sigils littering almost every function
declaration in Rust source, and I think that this is major contributor to
eye-soreness Rust syntax causes. Since '&' is so popular, couldn't Rust
just make it a default?
For instance, what if the following rule were be adopted:
