Tracking issue for slice::{ref_slice, mut_ref_slice}

@nikomatsakis

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

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

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.)

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

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

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.)

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!

👍 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.

Please stabilize these. Personally, I use them for reading single bytes from a reader (with read_exact).

The documentation says "Converts a pointer to A into a slice of length 1 (without copying)." Shouldn't "pointer" be "reference"?

std: Stabilize library APIs for 1.5

Auto merge of #29254 - alexcrichton:stabilize-1.5, r=brson

rust: Use crates.io ref_slice, as the libstd version was deprecated

Auto merge of #45306 - whitequark:ref_slice, r=alexcrichton

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

@nox

@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

OH WOW, I never saw that. Thanks!

Navigation Menu

Repository navigation

Tracking issue for slice::{ref_slice, mut_ref_slice} #27774

33 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for slice::{ref_slice, mut_ref_slice} #27774

Description

Activity

nikomatsakis commented on Aug 13, 2015

SimonSapin commented on Aug 13, 2015

alexcrichton commented on Sep 17, 2015

tbu- commented on Sep 17, 2015

nikomatsakis commented on Sep 17, 2015

alexcrichton commented on Sep 24, 2015

abonander commented on Sep 24, 2015

Stebalien commented on Sep 25, 2015

briansmith commented on Sep 25, 2015

33 remaining items

nox commented on Sep 19, 2019

Marwes commented on Sep 19, 2019

nox commented on Sep 19, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions