Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upRFC 401 should account for `Deref` coercions #1593
Comments
nrc
added
T-lang
P-high
I-nominated
labels
Apr 27, 2016
This comment has been minimized.
This comment has been minimized.
|
Nominating for discussion in the lang meeting (cc @rust-lang/lang). Assigning P-high so hopefully this issue doesn't get lost. |
nikomatsakis
removed
the
I-nominated
label
May 5, 2016
This comment has been minimized.
This comment has been minimized.
|
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 Since extending to fully transitive coercions would be backwards compatible, we're not going to pursue it at this time, but maybe later. |
nikomatsakis
added
P-high
and removed
P-high
labels
May 6, 2016
This comment has been minimized.
This comment has been minimized.
|
(To be clear, it'd still be good to update the RFC to reflect the current semantics.) |
This comment has been minimized.
This comment has been minimized.
|
@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? |
nrc commentedApr 27, 2016
RFC 401 specifies coercions in Rust. However, it doesn't deal with the case of coercions caused by a type implementing the
Dereftrait (specified in RFC 241). In particular, should coercions due toDerefbe included in the transitivity case for implicit coercions? Currently the compiler does not (I'm not even sure of the precise behaviour when combiningDerefcoercions with other coercions.cc rust-lang/rust#33220