Remix clone Hacker News

The hard problem is not sharing the trait, but sharing the trait instance.

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.

▲ zk4x 3 days ago | parent [-]

If there are two modules module_a and module_b, and each defines a function called foo, how does the compiler decide which foo should be used? It just checks whether you imported module_a::foo or module_b::foo.

▲ pyrale 3 days ago | parent [-]

The instance could be defined in module c.

▲ zk4x 3 days ago | parent [-]

Perhaps I should have been more clear. The point is you would not implement traits. You would just implement functions. You would not implemet traits, you would just write functions iter and len for your type.

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.

	▲	3 days ago \| parent \| next [-]
		[deleted]
	▲	pyrale 3 days ago \| parent \| prev [-]
		So you define your filter function by saying it can use anything that has the next and the len functions. Cool. 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?