On Nov 10, 2011, at 7:42 AM, David Rajchenbach-Teller wrote:
> - How do you compile the following extract?
>
> fn call_foo<T>(x: T) {
> x.foo();
> }
You don't. If you wanted to write `call_foo()`, you would probably write:
iface has_foo { fn foo(); }
fn call_foo(x: has_foo) {
x.foo();
}
then you could call this method like:
call_foo(x as has_foo)
In principle, it might be nice to allow something like bounded polymorphism:
fn call_foo<T:has_foo>(x: T) {
x.foo();
}
Without subtyping, it would make less sense. Perhaps it corresponds to passing
the vtable that converts a `T` into a `has_foo`, so when you invoke x.foo() it
compiles down to "T_vtable.foo(x)" (which I think is how Haskell type classes
work at runtime, but that's more from me guessing, perhaps people who know
Haskell better can correct me).
> > Perhaps we allow the syntax t.foo1::bar() to make it clear.
>
> What would you think of the following?
>
> (t as foo1(T)).bar()
Well, that makes a category into a type, which it currently is not.
> > Finally, this also raises the potential to have two instances of the
> > interace inter, both based on the same receiver, but with different vtables
> > and hence different definitions of bar()!
>
> What exactly is the issue there? Readability?
Just that it's potentially confusing. Here you have two instances of the same
interface, both bound to the same receiver, but they behave differently. I can
see some hard-to-find bugs arising this way.
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
