On 18/11/2011 11:30 AM, Brian Anderson wrote:
I'm worried that this rule is too clever. If I have some code like:
let a = "whatever";
let v = variant(a);
then 'a' is moved into 'v'. If I change the code later to use 'a' again
after the initialization of 'v' then variant(a) becomes a copy. I don't
know that there's actually any risk there, but it seems counterintuitive.
Ah, I see, this is how he's proposing to obviate the need for move-mode.
Just have last-use-into-copy-mode-argument do a move? And with the "warn
on big copy" behavior, the risk is ... mitigated.
I agree it feels a bit too clever / counterintuitive that way, but I
haven't used it much yet. It might be ok.
My initial thought is to add a unary "move" operator to mirror "<-", the
same way "copy" mirrors "=". Where "<-" and "move" now both really only
have the effect of turning the putative "large-copy warning" into a hard
error.
A careful author might well want to do this inside their module. I
certainly would, if I knew I was writing in "move style". I'd place the
moves where I think they should occur, to minimize the amount of "lval
last-use reasoning" I have to keep in my head, make it explicit.
(Especially if I had internalized the concept "move means fast"; who
doesn't want to add all the "go fast" symbols to their code they can? :)
Anyway, I think this is all definitely on the right track, but we might
need to play with it a bit more to get it feeling just right.
-Graydon
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
