On 12/6/11 11:47 PM, Marijn Haverbeke wrote:
I'd like to include immutable records of implicitly copyable types as
implicitly copyable.
I am not necessarily opposed but I'd prefer to have nominal records and
let the user specify per type (this could then apply to tags, too). My
reasoning is that the more "special cases" we make the less users will
understand. I could see the current rules being too complex, but I feel
like tuples are fairly special. If we do decide to go this route, I'd
like to see tags where all variants contain only implicitly copyable
things also be implicitly copyable: in other words, be consistent across
all kinds of types.
The primary use case for move mode arguments was to “give away” a unique
pointer: this is now achieved by having the callee simply declare a parameter
of unique type and having the caller move it to them.
When doing channel communication or data-structure construction,
there'll probably be a lot of calls that are 'giving away' arguments.
I fear that requiring callers to annotate every one of them will be
cumbersome. How about changing the semantics of by-move and by-copy
parameters to simply automatically insert the copy/move annotation
into every call?
I think you and I just see this issue differently. I see it as
burdensome if the caller does NOT specify that a variable is being moved
(or, for that matter, passed by mutable reference). This is because I
as reader of the code have no indication that this is not a simple, by
value parameter passing. I think your optimization where the last use
of a local variable is implicitly a move is a reasonable compromise, as
this is still something I can deduce just from reading the caller method
and without looking at the definitions of the functions that it calls.
That said, I feel better about the idea of making `move` mode a
suggestion to the caller (I would still say the caller should be able to
write `copy` or `move` explicitly) than I do about mutable by-ref
parameters. The reason is that if I try to use the variable after it
has been moved, I'll get an error, and if I don't try to use the
variable, then a move is reasonable. Still by this logic the "last use
is a move" rule ought to be enough.
When exactly would you want to have functions with a
non-single-word-sized return value not be constructor functions? I
still feel we'd be better off trying to make this implicit and not
exposing it to the user.
I agree: I did make it implicit. The `new` functions are not for this
purpose anymore. A `new` function is used to return something on the
heap without specifying which heap you are returning it on. It is
needed for returning variably sized types like arrays, because they
cannot be returned "by value", but at the same time you do not want to
have to write two versions of every array construction function:
fn map_shared<T,U>(v: [T], b: block(T)->U) -> @[U]
fn map_unique<T,U>(v: [T], b: block(T)->U) -> ~[U]
Using a `new` function allows you to write:
fn map<T,U>(v: [T], b: block(T)->U) -> new [U]
That said, we *could* hide (the new version of) `new` functions from the
user as well. Any function that returns a variably sized type would be
compiled using the `new` ABI. This includes functions with generic type
where the generic variable has the `var` capability/interface. I rather
like that as well. The need to specify the ABI for the return type is
one of the things I did not care for in this proposal. (In an earlier
draft of the proposal, I did not have the `var` interface for type
variables as I did not want to add a new kind. In that case, `new`
functions were needed)
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
