Tracking issue for `Vec::leak`

[cramertj]

Similar to Box::leak, this function would allow leaking a Vec and getting back an &'a mut [T].

[jonas-schievink]

Implementation in #62196

[SimonSapin]

Box::leak is an associated function instead of a method to avoid shadowing a possible Foo::leak method in Box<Foo>, normally accessible through auto-deref.

This is less relevant to Vec::leak since Vec<T> dereferences to [T]. There is no [T]::leak method in the standard library, so making Vec::leak a method would only shadow such a method if it’s defined in a user trait.

@cramertj Do you think it should still be an associated function?

[cramertj]

I don't have any particularly strong opinion. .leak() seems pretty clear to me, and users can always call it as Vec::leak if they prefer.

[Lucretiel]

Is there any reason to not have this method return an &'static mut [T]? It simplifies the code (no generic) and Rust can coerce the lifetime freely.

[rodrigorc]

I find weird that there is a Vec::leak, but not a String::leak, PathBuf::leak, OsString::leak or CString::leak.

IMHO, if Vec::leak exists, then any standard type that owns data and has a into_boxed_whatever member function should be able to leak too.

[cramertj]

IMHO, if Vec::leak exists, then any standard type that owns data and has a into_boxed_whatever 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 added independently.

[rodrigorc]

Sadly, I don't think there's a trait that covers these, so they'll all have to be added 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 len() function to have an is_empty() too, no trait involved. It's like an expected pattern.

[lambda-fairy]

@Lucretiel the lifetime parameter is necessary in case T has non-'static lifetimes, e.g. if it's a reference (playground).

Box::leak has a lifetime parameter for the same reason.

[shepmaster]

What do people think about changing the argument type to be more generic:

pub fn leak<'a>(vec: impl Into<Vec<T>>) -> &'a mut [T]
where
    T: 'a, 

I'm thinking about adding a similar String::leak and it'd be nice to do String::leak("hello").

[Lucretiel]

If we were to change it in this way, wouldn't it be preferable to use the Borrow machinery so that we can leak Vec<T> -> &[T], String -> &str, etc?

[SimonSapin]

I’d prefer to go in the opposite direction and change Vec::leak to be a proper method that takes a self parameter instead of an associated function with a vec: Self parameter. Any conversion can be a separate (chained) call.

Box::<T>::leak (like Box::into_raw etc) is an associated function rather than a method in order to avoid shadowing a potential T::leak method for some T types. But that does not apply to Vec which does not have Deref to a fully generic target type.