Rust: Tracking issue for `slice::from_ref` and `slice::from_ref_mut`

[whitequark]

Tracking issue for feature from_ref

// std::slice
pub fn from_ref<T>(s: &T) -> &[T];
pub fn from_ref_mut<T>(s: &mut T) -> &mut [T];

• Implemented in https://github.com/rust-lang/rust/pull/45306

[SimonSapin]

For archeology purpose: these were added to the standard library in 2014 419ac4a1b899ba88fb360b4c71c08f3610564cd4, then deprecated and moved to crates.io in 2015: https://github.com/rust-lang/rust/issues/27774.

Now that we’ve decided to bring them back and are going through the process motions, can we start FCP to stabilize? CC @rust-lang/libs

[dtolnay]

Is there anything else in the standard library that uses "ref_mut" to refer to &mut T? In RFC 199 we went the opposite way.

Is it intended to be understood as (from_ref)_mut or from_(ref_mut)?

slice::from_mut wouldn't seem accurate to me but is there a different naming that works better with _ref and _mut suffixes?

[whitequark]

Is it intended to be understood as (from_ref)_mut or from_(ref_mut)?

The latter. I think slice::from_mut is better here, too. I did not realize this in my initial PR.

[steveklabnik]

I had left a brief comment in the original PR, but I didn't see anyone reply: my crate has two extra Option based versions as well, I don't know if we want to pull them in, or if my crate will still have some small use for those variants.

[SimonSapin]

opt_slice(x) can be written as x.as_ref().map(ref_slice) which does not use unsafe (and is fairly standard Option manipulation code). So I think the need to include it is less pressing.

[whitequark]

@steveklabnik I replied to you: https://github.com/rust-lang/rust/pull/45306#issuecomment-340523116

[steveklabnik]

Gah! Thanks both! Seems great, I must have missed them in all the
notifications <3

On Thu, Nov 16, 2017 at 12:18 AM, whitequark [e-mail]
wrote:

@steveklabnik https://github.com/steveklabnik I replied to you: #45306
(comment)
https://github.com/rust-lang/rust/pull/45306#issuecomment-340523116

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rust/issues/45703#issuecomment-344818694,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABsimNkx0XAJV5H8vHL5kg8QcaoRSTZks5s28WygaJpZM4QO4RZ
.

[SimonSapin]

Looks good to me to stabilize.

@rfcbot fcp merge

[rfcbot]

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:

• [x] @Kimundi
• [x] @SimonSapin
• [x] @alexcrichton
• [ ] @aturon
• [x] @dtolnay
• [x] @sfackler
• [ ] @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and none object), 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.

[dtolnay]

Given that we have Option::get_ref and Option::get_mut which is not called get_ref_mut, I think here it should be from_ref and from_mut rather than from_ref_mut.

[SimonSapin]

Makes sense. Let’s say stabilize with that change.

[rfcbot]

:bell: This is now entering its final comment period, as per the review above. :bell:

[rfcbot]

The final comment period is now complete.

[stjepang]

Just one more last-minute question before stabilization: Why does slice::from_ref return a &[T]?

Wouldn't it be more useful to return a &[T; 1], which can be coerced into &[T]?
Are we going to add such a function later as array::from_ref?

[SimonSapin]

That’s… a good point.

Though as you say a function that returns &[T; 1] would belong more in std::array than std::slice. If we add it there, should we also remove it from std::slice (because you can get the same with coercion) or should we keep both?

[SimonSapin]

Yet another alternative might be From impls, instead of free functions.

[Kimundi]

I could image that implementing this with From impls might have negative inference or derfer-coercion effects, since passing a &Vec<T> for example might end in a &[Vec<T>] instead of a &[T]

[SimonSapin]

Right, adding another x.into() for every x: &T would probably make inference impractical.

[alexcrichton]

An excellent point @stjepang! It's a bit close to the release at this point, and I think @SimonSapin has a good idea of putting those in std::array as well