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 Bring back slice::ref_slice as slice::from_ref. #45306

[SimonSapin]

For archeology purpose: these were added to the standard library in 2014 419ac4a, then deprecated and moved to crates.io in 2015: #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: #45306 (comment)

[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 ***@***.***> wrote: @steveklabnik <https://github.com/steveklabnik> I replied to you: #45306 (comment) <#45306 (comment)> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#45703 (comment)>, 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:

• @Kimundi
• @SimonSapin
• @alexcrichton
• @aturon
• @dtolnay
• @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]

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

[rfcbot]

The final comment period is now complete.

[ghost]

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