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
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-ified Deref{,Mut}), and more general borrowing (e.g., &mut pinned_box being able to coerce to pinned_box.as_mut());
custom indexing/slicing.
without involving unsafe or other RefCast-like approaches;
when the reference type does not necessarily have the layout of a Rust reference (e.g., more embedded data (could be solved by ptr_metadata), or FFI requirements).
when other GAT APIs become widespread, and thus types such as <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 to Deref{,Mut})?
indexable[idx]
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:
reversing the relationship;
and/or having &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:
danielhenrymantilla
changed the title
_Quid_ of the sugared ops:: traits and GAT-ifying them
Quid of sugared ops:: traits and GAT-ifying them
Jan 25, 2022
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: