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
difference would be on the calling convention level.
I am thinking of how C++ fastcall calling convention handles function
arguments: anything that fits in 4 bytes is passed in registers, otherwise
it goes on stack. Also, in cdecl convention small return values go into
EAX register, whereas large ones are copied directly into the caller's
stack frame via a hidden pointer parameter. All this completely
transparent to the programmer (unless cross-language libraries are
involved, of course).
It seems to me that most of the borrow pointer usage in Rust is for
efficiency reasons, not because developer actually needs a pointer there.
Such code would work fine with by-value parameters, only slower.
BTW, it may also happen that the optimal value of the N threshold is
different on different platforms, so "by-ref vs by-value" decision may be
better left to whoever defines Rust ABI for that platform.
Regarding generics: Rust generics are reified to concrete types before code
is emitted, aren't they? After concrete parameter types are known, the
same optimization rule could be applied.
Finally, you might ask: "Why not just treat this as an optimization?".
Well, if this optimization is not a part of the language spec, developers
cannot rely on it, and will continue using &'s everywhere, just in case.
Kind of like tail recursion optimization is pretty useless unless
guaranteed by the language.
Vadim
On Thu, Apr 4, 2013 at 2:24 PM, Patrick Walton <pwal...@mozilla.com> wrote:
> 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 the following rule were be adopted: "All unadorned
>> function parameters are implicitly assumed to be passed by
>> borrow-reference"? Now, of course, this be inefficient for small types
>> like int, but that could be dealt with by specifying that types less
>> than N bytes in size (N perhaps being platform-dependent), are passed
>> by-value, except if mutable, or if adorned by lifetime of another
>> parameter.
>>
>> Ok, this is not a serious proposal, because I am probably missing a lot
>> of corner cases, but I would like to hear why this wouldn't work.
>>
>
> We tried this once ("modes"), and it was very confusing, especially when
> generics were involved.
>
> Patrick
>
> ______________________________**_________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev>
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
