Tracking issue for `as_slice` stabilization

[aturon]

Over time, the way that you convert e.g. a vector to a slice has transformed repeatedly. With deref coercions, it's usually implicit, but there are still some cases where you need to do it explicitly.

The as_slice method follows the usual conversion conventions, but has been somewhat controversial due to offering "yet another way" to perform the conversion (in addition to as_ref and &*).

[aturon]

FWIW, "there is only one way to do it" has never been a hard design rule for std, especially when it comes to convenience methods. I personally think there is little cost in having additional conversion methods that follow a strong convention.

[jethrogb]

There's also &vec[..].

[aturon]

Nominating for 1.5 FCP discussion.

[alexcrichton]

This issue is now entering its cycle-long FCP for conclusion at 1.5.

The libs team was a little up in the air about whether to deprecate or stabilize these methods. On one hand some are already stable (e.g. as_path) and these new methods follow clear existing conventiosn and don't come with much cognitive overhead. On the other hand these methods are very rarely called and it'll be another method to perform a similar task as the slicing syntax, for example.

[steveklabnik]

I'm generally 👎 on this, personally, for the "yet another way to do it" angle.

I haven't heard of anyone who is actually using as_slice() over slicing syntax, which indicates to me that it shouldn't exist.

[aturon]

cc @carllerche

[FranklinChen]

I was using as_slice() all the time before slicing syntax came along, then I switched, but Vec documentation https://doc.rust-lang.org/std/vec/struct.Vec.html could be improved, to explicitly mention slicing syntax early and up front and with examples.

[bstrie]

-1, unless you can present some damning case where all of the current three methods is insufficient. I'm already salty about having both &*x and &x[..]. Even if TIMTOWTDI isn't a hard rule, it's a very important guideline.

[jethrogb]

@bstrie do you mean TOOWTDI?