On 11/28/11 11:02 PM, David Herman wrote:
I guess what I was suggesting was that we currently have a notion of
types that *must not* be instances of `send`, and there's no way with
typeclasses to enforce *non*-implementation of an interface. But I'm
beginning to suspect that that's not a big deal. If you want to
declare that a type implements `send`, even when that type really
shouldn't be, you can go ahead and do it, but the implementation is
going to be silly. For example, you could declare that @int is
sendable with a no-op implementation. It's a stupid thing for a
programmer to do, but it's not unsafe. I think that's totally worth
living with, for the benefit of having `send` just be an iface. That
is such a win in terms of mental burden on the user.
The other day there was some off-list discussion about how this might
work. I just wanted to write it up and put it on the list and make sure
we're all on the same page. The basic idea is that there is a
well-known interface sendable, defined something like:
iface sendable {
fn send(chan: chan<self>);
}
(Note the implicit `self` variable; I think something like this will be
needed, though it introduces complexities. If we decide it's
infeasiable we can probably get rid of it. For now I will assume we can
make it work) Now when the compiler encounters an interface bound:
fn foo<S: sendable>(s: S) { ... }
it searches for an implementation of `sendable` as normal. Assuming
nothing is found, a special case rule kicks in: if the type matches our
definition of `sendable` (no transitive reference to an `@`), then a
default compiler implementation is used. An analogous process applies
for copy and log.
One twist that just occurred to me: sending a value *moves* the
receiver. We need a way to note that.
I like that this allows the user to customize how types can be copied,
logged, and sent. I think it works better in a nominal type system,
though, because otherwise you end up defining too much (i.e., you define
a rule for how to send all records with the same set of fields, rather
than the particular kind of record you meant). Maybe this is not a
problem in practice (kind of like duck typing, which seems to work fine
in practice).
Niko
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
