scottmcm

> I actually think the more compelling case for this is when you want to _not_ do something for the last item on the iterator. String joining being a classic...

> > So what if you did this as `.rev().enumerate().rev()`? Then you can check for `i == 0` for the last element. > > My 2c on this one is...

As another way of thinking of this: `Option` is iterable, thus it can be thought of as a container. It's, essentially, an `ArrayVec`, just with domain-specific method names (like `take`...

For another motivating example, I happened to notice this in the compiler today: https://github.com/rust-lang/rust/blob/65d2f2a5f9c323c88d1068e8e90d0b47a20d491c/compiler/rustc_hir_typeck/src/op.rs#L748-L749 which I'm pretty sure is the `Option` → `&[T]` under discussion here.

I'd suggest leaving it alone for now. PRs are easier if they're *just* library, or *just* compiler, etc. One can always make a follow-up PR later.

Hmm, a bigger survey might help for deciding on `into_slice`. Of the 4 examples mentioned upthread, it appears that at least 3 of them are going through `as_ref`, and thus...

`as_slice` and `as_mut_slice` stabilized in 1.75 🎉 Are you still interested in having `into_slice`, @llogiq ?

> It is tricky to handle it in LLVM :( Are there any small tweaks that we could do to what we emit to make it easier? For example, I...

One thing you might try on the hashbrown side: thanks to https://github.com/llvm/llvm-project/issues/56563, it seemed like using wider types for the `isize::MAX` check actually codegen'd well in https://github.com/rust-lang/rust/pull/100866, just was a...

So attributes on parameters were clearly helpful since there are multiple -- a function-level attribute would have had to match up the name or something, which would be awkward. But...