On 2014-05-30, at 4:16, Eric Reed <ecr...@cs.washington.edu> wrote:
> That was what I was referencing in my comment about the compiler getting
> scared and confused. Theoretically, it should be allowed and the compiler
> would just require you to specify, but rustc may not be there yet.
Are you saying that the compiler should be able to handle the following snippet
in the future?
(currently it says "error: conflicting implementations for trait `Foo`")
trait Foo {
fn foo(&self);
}
impl<X, T: Iterator<X>> Foo for T {
fn foo(&self) { /* arg implements Iterator */ }
}
impl<X, T: RandomAccessIterator<X>> Foo for T {
fn foo(&self) { /* arg implements RandomAccessIterator */ }
}
I guess this could be called trait implementation overloading and it
accomplishes the same goal as function overloading; if there is some overlap
between two or more impl's, then the compiler should always use the "most
specialized one" of the ones that could be used.
D language has, I think, a nice and simple way of specifying how function
overloading works:
Given two functions foo1 and foo2...
1) If foo1 can be called with arguments that have the parameter types of foo2
and if foo2 cannot be called with the parameter types of foo1, then foo2 is
"more specialized" than foo1.
2) If foo1 can be called with arguments that have the parameter types of foo2
and if foo2 can be called with the parameter types of foo1, then foo1 and foo2
are "equally specialized".
This way the "most specialized" function is determined and the function call
should resolve to that one. Function overloading is not allowed among functions
that are defined in different modules (to prevent what they call "function
hijacking"). And obviously, if there are multiple "most specialized" functions
that are "equally specialized", then that's an ambiguity error.
I remember seeing an edge case that showed that this way in which D specifies
function overloading is in some way inferior to the way C++ specifies it. But
the D way is a lot simpler to reason about.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
