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
{{ message }}
Repository navigation
Tracking issue for array::from_ref and array::from_mut #77101
Why is the mut version name differs from the slice variant? (from_ref_mut vs from_mut) Nvm, it's a typo in the issue description, the actual method is named from_mut.
What is blocking stabilization, it seems like there aren't any open questions/controversies. Shall I make a stabilization PR?
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
Since core::array::from_ref() and core::array::from_mut() has been stablized, could we now add impl<T> From<T> for [T; 1], impl<'a, T> From<&'a T> for &'a [T; 1] and impl<'a, T> From<&'a mut T> for &'a mut [T; 1] to libcore? These impls should be easy to implement (just one-liners) and ergonomic to use.
[...] could we now add impl<T> From<T> for [T; 1], impl<'a, T> From<&'a T> for &'a [T; 1] and impl<'a, T> From<&'a mut T> for &'a mut [T; 1] to libcore? [...]
Adding From<T> for [T; 1] could conflict with downstream From<Local> for [Local; 1].
Similarly, since & and &mut are "fundamental" and behave like their pointee for coherence purposes, downstream impls of From<&'a Local> for &'a [Local; 1] etc are also currently allowed, such that adding impl<'a, T: 'a> From<&'a T> for &'a [T; 1] would also conflict.
Adding another x.into() candidate for x: &T also was pointed out as possibly being an issue for type inference
.
Activity
WaffleLapkin commentedon Jan 17, 2021
Why is the mut version name differs from the slice variant? (Nvm, it's a typo in the issue description, the actual method is namedfrom_ref_mutvsfrom_mut)from_mut.What is blocking stabilization, it seems like there aren't any open questions/controversies. Shall I make a stabilization PR?
m-ou-se commentedon Apr 12, 2021
@rfcbot merge
rfcbot commentedon Apr 12, 2021
Team member @m-ou-se has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
rfcbot commentedon Apr 12, 2021
🔔 This is now entering its final comment period, as per the review above. 🔔
rfcbot commentedon Apr 22, 2021
The final comment period, with a disposition to merge, as per the review above, is now complete.
As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
The RFC will be merged soon.
Rollup merge of rust-lang#84105 - WaffleLapkin:stabilize_array_from_r…
Rollup merge of rust-lang#84105 - WaffleLapkin:stabilize_array_from_r…
oconnor663 commentedon Jun 12, 2021
Has anyone proposed to stabilize these? Could I just open a PR to start that? :)
WaffleLapkin commentedon Jun 12, 2021
@oconnor663 I've proposed. In fact, they were already stabilized :)
#84105
mzji commentedon Aug 4, 2021
Since
core::array::from_ref()andcore::array::from_mut()has been stablized, could we now addimpl<T> From<T> for [T; 1],impl<'a, T> From<&'a T> for &'a [T; 1]andimpl<'a, T> From<&'a mut T> for &'a mut [T; 1]to libcore? These impls should be easy to implement (just one-liners) and ergonomic to use.jhpratt commentedon Aug 4, 2021
@mzji Feel free to create a pull request! I would imagine it would be accepted.
zachs18 commentedon Jul 21, 2024
Adding
From<T> for [T; 1]could conflict with downstreamFrom<Local> for [Local; 1].Similarly, since
&and&mutare "fundamental" and behave like their pointee for coherence purposes, downstream impls ofFrom<&'a Local> for &'a [Local; 1]etc are also currently allowed, such that addingimpl<'a, T: 'a> From<&'a T> for &'a [T; 1]would also conflict.Adding another
x.into()candidate forx: &Talso was pointed out as possibly being an issue for type inference.