generated from rust-lang/project-group-template
-
Notifications
You must be signed in to change notification settings - Fork 6
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
Quid of sugared ops::
traits and GAT-ifying them
#3
Comments
danielhenrymantilla
changed the title
_Quid_ of the sugared
Quid of sugared Jan 25, 2022
ops::
traits and GAT-ifying themops::
traits and GAT-ifying them
Whoops, I raced with #2, lemme move this there |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
EDIT: see comment on #2
Based on the "GAT motivation" discussion over Zulip, and more precisely, around this question (archive link for those not on Zulip); people have started pondering about the idea that traits representing some of our sugary operations, such as
[…]
-indexing, or deref-coercions, could maybe be GAT-ified in some retro-compatible fashion, so that they not be required to necessarily yield&
or&mut
references respectively.Motivation
Plenty of examples in that Zulip thread; but people can also provide some to this very GH "issue".
But to summarize the main ones:
custom (re-)borrowing (e.g.,
Pin<&mut _>
) could be featured with a GAT-ifiedDeref{,Mut}
), and more general borrowing (e.g.,&mut pinned_box
being able to coerce topinned_box.as_mut()
);custom indexing/slicing.
unsafe
or otherRefCast
-like approaches;ptr_metadata
), or FFI requirements).<Ty as Trait>::Gat<'lt>
become more common.Questions:
What would exactly be the semantics of a GAT-ified operator such as
Index{,Mut}
(I suspect the same concerns apply toDeref{,Mut}
)?is actually sugar for a
*
-dereference (to a place expression) of the&Index::Output
or&mut Index::Output
(depending on the kind of usage of the place), so the starting point of these traits is&indexable[idx]
or&mut indexable[idx]
.Wouldn't GAT-ifying this result in either:
&indexable[idx]
not yield a&T
(and same for&mut
).This last idea seems like the most likely solution? Maybe?
How could the change be made in a retro-compatible fashion? I suspect we'll need new traits, to be the really sugared ones, and have the current ones be subsets which blanketly implement the new ones.
The text was updated successfully, but these errors were encountered: