Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Perhaps make orphan rules more permissive of associated types? #20590

Closed
nikomatsakis opened this issue Jan 5, 2015 · 5 comments
Closed

Perhaps make orphan rules more permissive of associated types? #20590

nikomatsakis opened this issue Jan 5, 2015 · 5 comments
Labels
A-associated-items Area: Associated items (types, constants & functions) A-type-system Area: Type system

Comments

@nikomatsakis
Copy link
Contributor

For now I'm treating associated types just like type parameters in coherence. I've given this approximately zero thought, it just seems like the conservative course, and we can always reverse it. For now it's largely a moot point since associated type references within impls don't work anyhow. Search the code for a FIXME.
@kmcallister kmcallister added A-associated-items Area: Associated items (types, constants & functions) A-type-system Area: Type system labels Jan 5, 2015
@nikomatsakis nikomatsakis changed the title Straighten out story of associated types and coherence Perhaps make orphan rules more permissive of associated types? Jan 8, 2015
@nikomatsakis
Copy link
Contributor Author

Updated title to make it clear that this would be an extension and hence is not a particular priority right now, especially absent a convincing use case.

@lambda-fairy
Copy link
Contributor

#20400 looks like a special case of this bug.

@nikomatsakis
Copy link
Contributor Author

Actually I think #20400 is a separate thing -- that's more about the other half of coherence, the overlap check.

@steveklabnik
Copy link
Member

Triage: would this be an RFC now? Post 1.0, a change like this feels pretty big.

@nikomatsakis
Copy link
Contributor Author

It's probably not as big as it sounds. Still I think we are probably doing the right thing here and afaik being conservative is causing us no problems. I'm just going to close the issue.

@oli-obk oli-obk mentioned this issue Sep 6, 2017
Open
nivkner added a commit to nivkner/rust that referenced this issue Oct 7, 2017
@nivkner
address more FIXME whose associated issues were marked as closed
e0ac65e 
update FIXME(rust-lang#6298) to point to open issue 15020
update FIXME(rust-lang#6268) to point to RFC 811
update FIXME(rust-lang#10520) to point to RFC 1751
remove FIXME for emscripten issue 4563 and include target in `test_estimate_scaling_factor`
remove FIXME(rust-lang#18207) since node_id isn't used for `ref` pattern analysis
remove FIXME(rust-lang#6308) since DST was implemented in rust-lang#12938
remove FIXME(rust-lang#2658) since it was decided to not reorganize module
remove FIXME(rust-lang#20590) since it was decided to stay conservative with projection types
remove FIXME(rust-lang#20297) since it was decided that solving the issue is unnecessary
remove FIXME(rust-lang#27086) since closures do correspond to structs now
remove FIXME(rust-lang#13846) and enable `function_sections` for windows
remove mention of rust-lang#22079 in FIXME(rust-lang#22079) since this is a general FIXME
remove FIXME(rust-lang#5074) since the restriction on borrow were lifted
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-associated-items Area: Associated items (types, constants & functions) A-type-system Area: Type system
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@steveklabnik @nikomatsakis @kmcallister @lambda-fairy