Tracking issue for slice::{ref_slice, mut_ref_slice}

[alexcrichton]

This is a tracking issue for the unstable ref_slice feature in the standard library. These functions seem fairly innocuous but it's also somewhat questionable how useful they are. They're probably ready for either stabilization or deprecation as-is.

cc @nikomatsakis

[nikomatsakis]

Speaking personally, I love these functions. I don't need 'em often, but when I do, I'm happy I have them. =)

[SimonSapin]

Although they are unsafe, the implementations of these functions are one-liners (based on slice::from_raw_parts{,_mut}) that can be easily replicated outside of std. So I wouldn’t miss them too much.

(Compare with functionality that may be rarely used but is impossibly to reasonably implement outside of std because e.g. it requires accessing private fields of std types.)

[alexcrichton]

Nominating for 1.5 resolution (I'd personally want to deprecate)

[tbu-]

It's a safe abstraction of unsafe code, I think it would be suited for the standard library.

[nikomatsakis]

Just to be clear for where I use this (in case you don't know), it's in a situation like this. Often I have an enum where the variants have different numbers of things associated with them (let's say integers here). Sometimes it's handy to match and only have to deal with the exact right number of integers for each case, but other times I want to just walk over all the integers. For some reason, it often happens that the variants have either 0, 1, or N such things. This works out quite nicely:

enum Foo {
    A, // no integers
    B(u32), // 1 integer
    C(Vec<u32>), // >1 integer
}

impl Foo {
    fn get_integers(&self) -> &[u32] {
        match *self {
            Foo::A => &[],
            Foo::B(ref i) => ref_slice(i),
            Foo::C(ref v) => v,
        }
    }
}

This seems to come up semi-regularly for me. (Sadly, the methods that let you go from &(T, T) to &[T] were removed, or it would work even for an arbitrary number of integers.)

The other situation where this fn comes in handy for me is when you have some generic helper that takes a &[T], but you happen to have an &T lying around. You can easily reuse this helper.

I think it's ok for this to live in libstd. It's not really duplicating anything else; I mean it's true you can write them in terms of other APIs, but only by dropping into unsafe code and going into a whole 'nother level of abstraction.

(That said, if there were to be another crate that ALSO included the ability to convert tuples into slices and so forth, that's more interesting. Though that's probably something we can't "safely" do until we agree to commit to the way tuples are represented in memory, though I could never imagine us changing this.)

[alexcrichton]

This issue is now entering its cycle-long FCP for resolution in 1.5

The libs team was a little up in the air about deprecation or stabilization here, comments are certainly welcome!

[abonander]

👍 It's somewhat superfluous, yes, but being that it's a safe wrapper around unsafe code it's not a bad abstraction overall. It'd just end up in some utility crate somewhere, like the Apache Commons for Rust.

[nox]

Note that with the recent effort to reduce the amount of dependencies in some projects, we end up downstream copying the functions in their own crate rather than having one more dependency.

This is IMO quite unfortunate and that's more unsafe code to review for everyone.

https://github.com/CraneStation/cranelift/blob/c47ca7bafc8fc48358f1baa72360e61fc1f7a0f2/cranelift-codegen/src/ref_slice.rs#L1-L8

[Marwes]

@nox These were brought back to life quite some time ago https://doc.rust-lang.org/std/slice/fn.from_ref.html https://doc.rust-lang.org/std/slice/fn.from_mut.html

[nox]

OH WOW, I never saw that. Thanks!