On 09/24/2011 04:45 PM, Graydon Hoare wrote:
On 24/09/2011 1:02 PM, [email protected] wrote:
This test tries to swap unique boxes containing resources, which is not
allowed.
Hi. I know I'm officially on break now but I did see this go past
while checking on other things, and wanted to point out that (though
it's counter-intuitive) I think this is not quite right. In
particular, if you look at the comment in kind.rs you'll see that it
says:
Hi Graydon. Sorry for pulling you out of your vacation on day one! Sadly
I don't understand kinds.
MOVE + NOSEND = "Shared": structures containing @, fixed to the local
task heap/pool; or ~ structures pointing to
pinned values.
That is, a ~ box containing pinned-kind lowers to shared-kind, not to
pinned itself. This is to prevent it moving over channels (localizing
it to the current heap) but not prevent swapping pointer-to-resource,
which seems to be the only useful way to make a resource have
indefinite extent (live as long as a data structure).
My motivation for lowering uniques kinds containing pinned kinds to
pinned was an intuition that shared kinds are copyable, but on further
review of the comments in kind.rs, copyability doesn't seem to be a
direct property of a type's kind.
I realize that "~resource" doesn't "look shared" in an intuitive
sense, but it's a bit of a corner case and I think it's the right
rule; other rules involve having move/swap/copy discriminate by type
constructor first ("is this a box? if so, look at content-kind, else
look at total-kind") which feels clunkier.
I think that according to guidance in kind.rs that copy rules do have to
discriminate by type constructor:
* A copy is made any time you pass-by-value or execute the = operator in a
* non-init expression.
*
* @ copies shallow, is always legal
* ~ copies deep, is only legal if pointee is unique.
* pinned values (pinned resources, alias-closures) can't be copied
* all other unique (eg. interior) values copy shallow
*
* Note this means that only type parameters constrained to ~T can be
copied.
So, the ability to copy a unique box is based on the kind in the box,
regardless of the unique box's kind. A unique box of resource (shared
kind) is not copyable; a unique box of int (unique kind) is copyable.
The comments in kind.rs frame the kind system in terms of move and send.
I have a hard time understanding the role that send plays here, since
send is not a concept in the rust language. There is a definition of
send as 'sending is accomplished by calling a move-in operator on
something constrained to a unique type ~T' (and I assume this should
read 'unique kind ~T'). This seems sort of tautological as send is used
in defining what a unique kind is.
Copying seems to be a big concern here and I feel like the kind system
would be easier to grasp if it were defined in terms of move and copy
instead of move and send.
I also don't understand why resources can't be moved, and to me it seems
like the key property of pinned things is that they can't be copied.
Regards,
Brian
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
