Trait reform

[nikomatsakis]

CURRENT STATUS:

A lot of work has been done and there are only a few remaining tasks.

• Modify method dispatch to use trait machinery #17918: Modify method dispatch to use trait selection machinery, so that multi/conditional-dispatch works.
• Implement where clauses #17657: Generalized where clauses
• Orphan rules in coherence do not account for multidispatch #18222: Orphan rules
• Remove the remaining uses of old_orphan_rules #19470: Coherence rules

EXAMPLES:

Here are some issues that contain test cases that ought to work once this is done:

• Regression in method resolution through Deref #17594

ORIGINAL TEXT:

This is an umbrella issue for collecting together issues with the current trait system. We need to figure out precisely what the solutions will be and discuss at the retreat, but it's at least useful to know what the problems are.

[nikomatsakis]

Related blog posts:

http://smallcultfollowing.com/babysteps/blog/2013/04/02/associated-items/
http://smallcultfollowing.com/babysteps/blog/2013/04/03/associated-items-continued/

[nikomatsakis]

One issue is that we assume in some parts of the code (but not all) that you can only implement a trait with one given set of type parameters (added FIXMEs).

[brendanzab]

Associated items, as outlined in @nikomatsakis' post, would be very useful for #4819 (Bikeshed Numeric Traits). I'm in the process of drawing up a proposal for the numeric trait hierarchy which shows off how these could be used. I realize however that this might have to be post-1.0.

[nikomatsakis]

Nominated for backwards compat and/or well-defined

[nikomatsakis]

We currently limit types from implementing the same trait more than once with distinct type parameters. I once proposed this limitation but have come to the conclusion that it is too limiting, and we should go more in the direction of haskell multiparameter type classes + associated types. There are various FIXMEs scattered throughout the code. Here is an example (from bjz) that fails because of this: https://gist.github.com/bjz/fbf54b214b36aeed471e

[graydon]

accepted for well-defined milestone

[catamorphism]

Bug triage; it's all good.

[catamorphism]

De-milestoning because it's a metabug and its sub-bugs are milestoned.

[nikomatsakis]

Nominating -- in particular there are some open questions.

[pcwalton]

Nominating to remove from blocker list because this is a metabug. If the scope of this bug is "everything that's weird with traits" then we'll never hit 1.0. Firefox has a policy of not blocking on metabugs for this reason too.

[nikomatsakis]

I don't consider that the scope of the bug exactly. Let me write up a concrete proposal.

[erickt]

@nikomatsakis said this example falls under this metabug. I tried to add this implementation to Iterator:

impl<'self, A, T: Iterator<T>> Iterator<T> for &'self mut T {
    fn next(&mut self) -> Option<A> {
        (*self).next()
    }

    fn size_hint(&self) -> (uint, Option<uint>) {
        (*self).size_hint()
    }
}

But it hit an odd conflict within vec.rs, where rustc is now finding Iterator::len (which vecs do not directly implement) is conflicting with Container::len (which vecs do implement):

/Users/erickt/rust/rust/src/libstd/vec.rs:1433:29: 1433:41 error: failed to find an implementation of trait iter::Iterator<~[T]> for ~[T]
/Users/erickt/rust/rust/src/libstd/vec.rs:1433         if self.capacity() - self.len() < n {
                                                                            ^~~~~~~~~~~~

[pnkfelix]

We need a write up of Trait algorithm and stamp that as "1.0 approved". We don't have it yet. I'll open a fresh bug for that. For now removing the P-tag from this bug.