IssueRaiser

Tracking issue for RFC 2532, "Associated type defaults"

This is a tracking issue for the RFC "Associated type defaults" (rust-lang/rfcs#2532) under the feature gate `#![feature(associated_type_defaults)]`. -------------------------- The [associated item RFC](https://github.com/rust-lang/rfcs/pull/195) included the ability to provide defaults for associated types, with some tricky rules about how that would influence defaulted methods. The early implementation of this feature was gated, because there is a widespread feeling that we want a different semantics from the RFC -- namely, that default methods should not be able to assume anything about associated types. This is especially true given the [specialization RFC](https://github.com/rust-lang/rfcs/pull/1210), which provides a much cleaner way of tailoring default implementations. The new RFC, rust-lang/rfcs#2532, specifies that this should be the new semantics but has not been implemented yet. The existing behavior under `#![feature(associated_type_defaults)]` is buggy and does not conform to the new RFC. Consult it for a discussion on changes that will be made. -------------------------- ### Steps: - [ ] Implement rust-lang/rfcs#2532 (cc @rust-lang/wg-traits @rust-lang/compiler) - [X] #61812 - [x] handle https://github.com/rust-lang/trait-system-refactor-initiative/issues/46 - [ ] Implement the changes to object types specified in the RFC - [ ] Improve type mismatch errors when an associated type default can not be projected (https://github.com/rust-lang/rust/pull

Posted by aturon on Nov 6, 2015, 6:21 PM

Tags

Related issues

Raise real-world problems, find people facing the same issue, and discuss solutions.5,000 issues0 comments

github (Software)

Tracking issue for RFC 2532, "Associated type defaults"

aturonNov 6, 2015, 6:21 PM

This is a tracking issue for the RFC "Associated type defaults" (rust-lang/rfcs#2532) under the feature gate `#![feature(associated_type_defaults)]`. -------------------------- The [associated item RFC](https://github.com/rust-lang/rfcs/pull/195) included the ability to provide defaults for associated types, with some tricky rules about how that would influence defaulted methods. The early implementation of this feature was gated, because there is a widespread feeling that we want a different semantics from the RFC -- namely, that default methods should not be able to assume anything about associated types. This is especially true given the [specialization RFC](https://github.com/rust-lang/rfcs/pull/1210), which provides a much cleaner way of tailoring default implementations. The new RFC, rust-lang/rfcs#2532, specifies that this should be the new semantics but has not been implemented yet. The existing behavior under `#![feature(associated_type_defaults)]` is buggy and does not conform to the new RFC. Consult it for a discussion on changes that will be made. -------------------------- ### Steps: - [ ] Implement rust-lang/rfcs#2532 (cc @rust-lang/wg-traits @rust-lang/compiler) - [X] #61812 - [x] handle https://github.com/rust-lang/trait-system-refactor-initiative/issues/46 - [ ] Implement the changes to object types specified in the RFC - [ ] Improve type mismatch errors when an associated type default can not be projected (https://github.com/rust-lang/rust/pull

Comments (0)

No comments yet. Start the discussion.

Comment on this issue