> 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".
I see. This is what I meant when I said " we can introduce a copying
argument mode" -- it'd be like move-mode, but force a copy instead. I
suggest, however, that this is so useless that it's not worth the
added complexity.
> 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...
Actually, by our current semantics, 'fn<T>(x: &T) -> T { x }' is
already a copy operation, since ret always copies. (In my proposal,
you would drop the &, it'd still work) Unfortunately, we generate so
much dynamic-size cruft for such a function that it's not a very
efficient copy operation, even when inlined. Once we have
specializing, guaranteed-inline library function, this would be a good
option.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
