With your solution, if too modules define traits with identical type signatures but different implementations, it would be impossible for the compiler to decide which impl to use.
When calling a function, compiler would check separately for existence of each function defined in the trait. That is a trait would be just like any other type alias so that you do not need to repeating complex function names everywhere:
You could write:
trait Iterator = fn next<T>(&mut self) -> Option<T> + fn len(&self) -> usize
fn filter(iter: impl Iterator)
but that would be just syntactic sugar for this: fn filter(iter: fn next<T>(&mut self) -> Option<T> + fn len(&self) -> usize)
Basically removing traits alltogether, just relying on functions.If a type A defined in module_a doesn’t have the functions defined in its module, should it still be filterable?
If the required function is defined in a module_b should A be filterable?
This is why I don’t have interest in learning rust. When I see people write c++ code like this I wonder why they feel the need to be so clever.
That is an abysmal thing to maintain.
It's not even "clever". It's completely plain, and the bare minimum and obvious definition of what an "iterator" should be.
Perhaps we need to go back to the basics a bit? What is a trait? 1. A set of functions, associated types and generic types 2. A marker/tag (e.g. Send, Sync)
Orphan rules do not seem to be problem for marker traits. Library authors must be responsible for enforcing whether their types are Send/Sync, etc or not.
As for normal traits, it's too late for rust, but I'd just limit traits to being only sets of function definitions, e.g.
trait Iterator = fn next<T>(&mut self) -> Option<T> + fn len(&self) -> usize
Then adding set operations (and, or, xor, not) for traits would be pretty easy, keeping most of power for defining generics.
More importantly traits could be just aliases and two traits with the same set of functions would be equal. This solves orphan problem - you would not need to import or export traits, it would be just normal resolution of functions. Do I call this function from crate A, or crate B? That's a solved problem.