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.

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

RFC 401 should account for `Deref` coercions #1593

Open
nrc opened this Issue Apr 27, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@nrc
Copy link
Member

nrc commented Apr 27, 2016

RFC 401 specifies coercions in Rust. However, it doesn't deal with the case of coercions caused by a type implementing the Deref trait (specified in RFC 241). In particular, should coercions due to Deref be included in the transitivity case for implicit coercions? Currently the compiler does not (I'm not even sure of the precise behaviour when combining Deref coercions with other coercions.

cc rust-lang/rust#33220

@nrc

This comment has been minimized.

Copy link
Member Author

nrc commented Apr 27, 2016

Nominating for discussion in the lang meeting (cc @rust-lang/lang). Assigning P-high so hopefully this issue doesn't get lost.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented May 6, 2016

We discussed this in the @rust-lang/lang meeting. We decided that while we would probably prefer for coercions to be transitive, we are not entirely comfortable with the implications of trying to make "deref" and "unsizing" coercions transitive with respect to one another. If nothing else, this could be very expensive from a compilation time point of view.

Consider coercing from &Box<T> to &SomeTrait, where T: SomeTrait. This would in principle require first checking whether Box<T>: SomeTrait (slash the unsizing rules etc), then deref to &T, then check again for T: SomeTrait. Maybe not a problem, but certainly not cheap.

Since extending to fully transitive coercions would be backwards compatible, we're not going to pursue it at this time, but maybe later.

@nikomatsakis nikomatsakis added P-high and removed P-high labels May 6, 2016

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented May 6, 2016

(To be clear, it'd still be good to update the RFC to reflect the current semantics.)

@brson

This comment has been minimized.

Copy link
Contributor

brson commented Jun 23, 2016

@nikomatsakis Is this supposed to be P-high. It sounds like you are saying we just need to fix the RFC. Can you assign someone to this or demote it, or close it?

@brson brson removed the P-high label Jun 23, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.