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.

[Stebalien]

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

[briansmith]

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

[SimonSapin]

Yes.

[canndrew]

Definitely stabilize. Don't force me to use unsafe for something so simple.

[photino]

Personally, I would like to see that they are deprecated. They are simple wrappers of the unsafe code but not marked as unsafe. This is somewhat confusing and inconsistent.

[abonander]

@photino They are not marked unsafe because it's safe to convert any &T or &mut T where T: Sized to, respectively, &[T] or &mut [T] with a length of 1. The layout of the data in the pointed-to area of memory is the same, it doesn't extend the lifetime of the reference, and it doesn't change an &T to an &mut [T].

This is absolutely consistent and is actually a very concise example of a core Rust idiom: that safe wrappers can be created around unsafe code if they can guarantee certain invariants. Here, the invariants are just very easy to enforce.

[photino]

@cybergeek94 Thanks for your explanation. I can't figure out any other reasons for not providing such safe wrappers.

[alexcrichton]

The libs team discussed this during triage today and the decision was to deprecate these functions. The standard library currently doesn't house many nuggets of functionality like this (e.g. see the recent discussions around Box::leak), and we've also deprecated similar functionality (Option::as_slice).

While certainly useful from time to time, it's not clear that these functions belong in the standard library right now. There can always be a helper crate implementing all sorts of conversions like this, however!

[canndrew]

That seems like a really weird decision. This is such a fundamental conversion between primitive datatypes it probably belongs at the language level (ie. &x as &[T]). In C they are the same type. The standard library has stuff for doing networking, hashing, spawning processes and threads all of which could be spun off into separate libraries but if I want to treat a value as an array of length one I need an auxiliary crate?

What does it matter if people only need it from time to time? It's such a trivial function it's not like it's adding bloat.

[canndrew]

I mean it's like saying "Oh sure you can parse the file table of a fat32 drive out-of-the-box but if you want to upcast a u32 to a u64 you'll need to download the int_conversion crate". That kinda weird.

[nikomatsakis]

My opinion was also informed by a conversation with Paul Pedriana, who said
that at EA they disable TBAA because it's too hard for them to reason about
and buys too little. (I also find the rules hard to reason about,
personally.) In any case, I suspect the importance of TBAA for optimization
will depend a lot on what piece of code we're talking about, also -- i.e.,
maybe it is crucial for auto-vectorization, where more reordering is
necessary, but less crucial for other things, or something like that.
Anyway, somewhat off-topic for this thread I guess (though @arielb1's
original point was correct, that rules like TBAA will affect whether
ref_slice is valid unsafe code or not).

/me disappointed by decision to remove ref_slice, but moving on with his
life. ;)

On Fri, Oct 23, 2015 at 4:04 AM, Vadim Petrochenkov <
notifications@github.com> wrote:

Yeah I was under the impression that TBAA had become quite maligned in
recent years.

https://lwn.net/Articles/316126/ :D
And I've seen a lot of similar frustration on isocpp forums from people
doing low-level programming.

On the other hand I've heard from Clang developers that TBAA is crucial
for C++ performance (and similarly for performance of Rust raw pointers, I
suppose), that's why they push for even stricter aliasing rules.

—
Reply to this email directly or view it on GitHub
#27774 (comment).

[steveklabnik]

If anyone still wants these functions, I put them in a small crate: https://crates.io/crates/ref_slice

[arielb1]

@nikomatsakis

Will we specify that ref_slice is legal?

[huonw]

The lang team decided that &mut T -> &Cell<T> wasn't crazy, so I imagine tupling on a 1_usize to a pointer is OK.

[tbu-]

@huonw Do you have a link to that decision?

[huonw]

That crate and its documentation. (You might be able to get the actual things that were written down at the time in the lang team meeting minutes somewhere in July or August, but I don't think they'll offer anything more than that link.)

[tbu-]

@steveklabnik Thanks for the crate.

[notriddle]

https://botbot.me/mozilla/rust/2015-06-09/?page=19

[tbu-]

@notriddle Thanks.

[huonw]

NB. that discussion isn't the lang team (I believe it was an independent invention of the same idea). The notes that were taken are at the end of https://github.com/rust-lang/meeting-minutes/blob/master/lang-team/2015-07-23.md

[tbu-]

@huonw Thank you, I tried finding them, but I didn't.