Change:
/// Simple usage: /// /// ``` <del> /// #![feature(vec_leak)] /// </del> /// let x = vec![1, 2, 3]; <del> /// let static_ref: &'static mut [usize] = Vec::leak(x); </del> <ins> /// let static_ref: &'static mut [usize] = x.leak(); </ins> /// static_ref[0] += 1; /// assert_eq!(static_ref, &[2, 2, 3]); /// ``` <del> #[unstable(feature = "vec_leak", issue = "62195")] </del> <ins> #[stable(feature = "vec_leak", since = "1.47.0")] </ins> #[inline] <del> pub fn leak<'a>(vec: Vec<T>) -> &'a mut [T] </del> <ins> pub fn leak<'a>(self) -> &'a mut [T] </ins> where T: 'a, // Technically not needed, but kept to be explicit. { <del> Box::leak(vec.into_boxed_slice()) </del> <ins> Box::leak(self.into_boxed_slice()) </ins> } }

Discussion:
Similar to , this function would allow leaking a and getting back an .
Implementation in
is an associated function instead of a method to avoid shadowing a possible method in , normally accessible through auto-deref. This is less relevant to since dereferences to . There is no method in the standard library, so making a method would only shadow such a method if it’s defined in a user trait. Do you think it should still be an associated function?
I don't have any particularly strong opinion. seems pretty clear to me, and users can always call it as if they prefer.
Is there any reason to not have this method return an ? It simplifies the code (no generic) and Rust can coerce the lifetime freely.
I find weird that there is a , but not a , , or . IMHO, if exists, then any standard type that owns data and has a member function should be able to leak too.
Seems fine to me. Sadly, I don't think there's a trait that covers these, so they'll all have to be independently.
I don't think the lack of trait is a problem at all. For example I would expect any standard type that has a function to have an too, no trait involved. It's like an expected pattern.
the lifetime parameter is necessary in case has non- lifetimes, e.g. if it's a reference (). has a lifetime parameter for the same reason.
What do people think about changing the argument type to be more generic: I'm thinking about adding a similar and it'd be nice to do .
If we were to change it in this way, wouldn't it be preferable to use the machinery so that we can leak , , etc?
I’d prefer to go in the opposite direction and change to be a proper method that takes a parameter instead of an associated function with a parameter. Any conversion can be a separate (chained) call. (like etc) is an associated function rather than a method in order to avoid shadowing a potential method for some types. But that does not apply to which does not have to a fully generic target type.
You and I have had this discussion for other types so I won’t restate my previous positions against this.

Vec::leak itself doesn’t need to exist and can be a separate (chained) call — vec -boxed slice -box::leak
I’m not following how this would work; would you mind expanding a bit?
So, your proposal is that we have be generic over , with the motivating example being that you can a . However, my argument is that it's surprising for a to leak into a , and that instead the trait (which universally genericizes & associates between owned and borrowed versions of things (eg, , , ) could be used instead. Though, now that I'm thinking about it, I think it also does , so it may actually be too abstract for this purpose.
I’m sorry, I don’t remember the specifics so if you have a link to those discussions I wouldn’t mind. By "chained" I was referring specifically to method chaining syntax , where parens do not need to be nested. In this case, .
Ah, sorry, that's not what I meant. I mean to add another method: in the same vein as and .
Ah, yes, I definitely can support that.
But wait, so- that means (for example) that something like would be valid? I'm not sure I love that; it seems like it'd be more confusing than other cases of in method definitions. My expectation is to "leak a ", and I'd argue it's reasonable in this case for the user to manage getting a they want to leak in the first place. Additionally, can I ask you to elaborate on this a bit? It makes perfect sense to me for smart-pointer types like , , etc, but I'm not sure I see the argument for or .
I'd rather not as I've always lost that particular argument. No reason to believe that this time will be any different.
I’ve proposed FCP to stabilize with a signature change at