You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The "special types" page lists Rc, Arc and a few others as special because they can be method receivers. This is achieved by them implementing a magic trait, Receiver. Given that, shouldn't we do the same for other magic traits? The ones I can think of right now are CoerceUnsized and DispatchFromDyn.
Relatedly, CoerceUnsized and Unsize are actually mentioned in the docs ("type coercions"), but Receiver and DispatchFromDyn are not.
The text was updated successfully, but these errors were encountered:
Receiver was intentionally excluded since it isn't stable, so the few types that are allowed on stable were listed explicitly instead. But, yea, that is inconsistent with CoerceUnsized. I would say, if the reference intends to stick to the stable language definition, then it should only explain the visible effects, or make it clear these traits are internal (and list the types where it is exposed). Either way is a little awkward, though.
Also, see #591, the "special types" page isn't exhaustive, and I suspect there are other types that could be added. I also expected Receiver to get stabilized, which would remove some of the awkward description, but that has taken longer than I expected.
The "special types" page lists
Rc
,Arc
and a few others as special because they can be method receivers. This is achieved by them implementing a magic trait,Receiver
. Given that, shouldn't we do the same for other magic traits? The ones I can think of right now areCoerceUnsized
andDispatchFromDyn
.Relatedly,
CoerceUnsized
andUnsize
are actually mentioned in the docs ("type coercions"), butReceiver
andDispatchFromDyn
are not.The text was updated successfully, but these errors were encountered: