IssueRaiser

Tracking issue for specialization (RFC 1210)

<!-- homu-ignore:start --> *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/issues/31844)* <!-- homu-ignore:end --> This is a tracking issue for specialization (rust-lang/rfcs#1210). Major implementation steps: - [x] Land https://github.com/rust-lang/rust/pull/30652 =) - [ ] Restrictions around lifetime dispatch (currently a **soundness hole**) - [ ] `default impl` (https://github.com/rust-lang/rust/issues/37653) - [ ] Integration with associated consts - [ ] Bounds not always properly enforced (https://github.com/rust-lang/rust/issues/33017) - [ ] Should we permit empty impls if parent has no `default` members? https://github.com/rust-lang/rust/issues/48444 - [ ] implement "always applicable" impls https://github.com/rust-lang/rust/issues/48538 - [ ] describe and test the precise cycle conditions around creating the specialization graph (see e.g. [this comment](https://github.com/rust-lang/rust/pull/70535#discussion_r401685535), which noted that we have some very careful logic here today) Unresolved questions from the RFC: - Should associated type be specializable at all? - When should projection reveal a `default type`? Never during typeck? Or when monomorphic? - Should default trait items be considered `default` (i.e. specializable)? - Should we have `default impl` (where all items are `default`) or `partial impl` (where `default` is opt-in); see https://github.com/rust-lang/rust/issues/37653#issuecomment-616116577 for some relevant

Posted by nikomatsakis on Feb 23, 2016, 5:35 PM

Tags

Related issues

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

github (Sysadmin)

Tracking issue for specialization (RFC 1210)

nikomatsakisFeb 23, 2016, 5:35 PM

<!-- homu-ignore:start --> *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/issues/31844)* <!-- homu-ignore:end --> This is a tracking issue for specialization (rust-lang/rfcs#1210). Major implementation steps: - [x] Land https://github.com/rust-lang/rust/pull/30652 =) - [ ] Restrictions around lifetime dispatch (currently a **soundness hole**) - [ ] `default impl` (https://github.com/rust-lang/rust/issues/37653) - [ ] Integration with associated consts - [ ] Bounds not always properly enforced (https://github.com/rust-lang/rust/issues/33017) - [ ] Should we permit empty impls if parent has no `default` members? https://github.com/rust-lang/rust/issues/48444 - [ ] implement "always applicable" impls https://github.com/rust-lang/rust/issues/48538 - [ ] describe and test the precise cycle conditions around creating the specialization graph (see e.g. [this comment](https://github.com/rust-lang/rust/pull/70535#discussion_r401685535), which noted that we have some very careful logic here today) Unresolved questions from the RFC: - Should associated type be specializable at all? - When should projection reveal a `default type`? Never during typeck? Or when monomorphic? - Should default trait items be considered `default` (i.e. specializable)? - Should we have `default impl` (where all items are `default`) or `partial impl` (where `default` is opt-in); see https://github.com/rust-lang/rust/issues/37653#issuecomment-616116577 for some relevant

Comments (0)

No comments yet. Start the discussion.

Comment on this issue