On 09/25/2011 12:31 PM, Graydon Hoare wrote:
On 24/09/2011 5:36 PM, Brian Anderson wrote:
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.
Yes. I notice that the rules in the kind checker don't actually do
this discrimination; shame on me, sorry. They permit copying anything
shared-kind. That's too loose; permits copying ~resource deeply. Dammit.
ty::type_kind calculates the kind of ~resource incorrectly too. Yuck
all around. This is not going to be fun to fix. Might require
algorithmic changes to much of the code in std::vec to avoid copies it
thinks it can get away with.
I added the calculation for unique box of pinned recently so that
shouldn't be too hard to change; just need to make sure unique box of
resource is non-copyable. Incidentally, I'm finding the overloading of ~
and 'unique' to be quite difficult to communicate about - I think you're
refering to unique boxes of resource. I also changed [resource] to be
pinned (from shared), assuming that the old calculation was valid for
evecs, not ivecs. Is that correct?
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.
"Send" is a concept *expressed by* the kind system. IOW it's not that
the kind system is defined solely in terms of "some other operator";
the kind system exists in order to *encode* a few concepts that are
not otherwise linguistically encoded: no-send and no-move. Despite the
fact that no "language level" constructs correspond to these
motivations, there are *very real* pragmatic safety considerations
requiring us to prohibit those in 2 cases:
- no-send is required to prohibit data racing between tasks; tasks
don't exist at a language level but they very much do exist in
the runtime and in the minds of every user looking at the language.
- no-move is required to prohibit &-closures (blocks) from
escaping to the heap, thus pointing to dead stack frames.
Why can't no-move just be no-send, and then make shared types
un-movable? Is there something useful that can be done by moving shared
types (besides saving some refcounting)? The entire (maybe? at least the
biggest) motivation for move is send, and it would be easier to think of
them as the same thing.
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.
Because &-closures are pinned and they must not escape to the heap.
It seems like resource and fn& are different kind, or at least the kind
system doesn't fully express what can be done with each. For example,
~resource becomes a shared kind which can escape, ~fn& can't be a shared
kind.
Regards,
Brian
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
