Tracking Issue for vec::push_with_ref

[ObamaTheLlama114]

Feature gate: #![feature(vec_push_with_ref)]

This is a tracking issue for Vec::push_with_ref

Similar to Vec::push, but returns a reference to the elements new spot in memory.

Public API

// alloc::Vec

impl Vec<T, A> {
    pub fn push_with_ref(&mut self, value: T) -> &T;
}

Steps / History

• Implementation: Vec::push_with_ref #104079
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• naming (eg. push_with_ref)

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[leonardo-m]

What's the purpose of this method?

[Uriopass]

The problem with theses kinds of methods in general is that the lifetime of the &T is tied to the lifetime of &mut self. Therefore you cannot use a &self method on the vec after getting the reference.
example:

struct A(i32);

impl A {
    fn incr_and_ref(&mut self) -> &i32 {
        self.0 += 1;
        &self.0
    }
    
    fn get(&self) -> &i32 {
        &self.0
    }
}

fn main() {
    let a = A(0);
    let a_ref = a.incr_and_ref();
    let a_ref_2 = a.get(); // not allowed, even though in theory we only hold an immutable ref to the inner value of a
    println!("{} {}", a_ref, a_ref_2)
}

[ObamaTheLlama114]

The problem with theses kinds of methods in general is that the lifetime of the &T is tied to the lifetime of &mut self. Therefore you cannot use a &self method on the vec after getting the reference. example:

...

Yes I am coming to realize that. Is there any way around this issue?

[ObamaTheLlama114]

What's the purpose of this method?

To my knowledge the only way to do this now is to push to the vec and then get the last element of the vec, which doesnt feel very thread safe to me, and also kinda just feels icky. This provides a more thread safe alternative.

[ObamaTheLlama114]

Also apologies for responding so late

[Uriopass]

Rust is not like Go. Safe rust cannot have data races.
Your method is not more thread safe than pushing and getting because pushing requires &mut T which means you have exclusive access to the vec.

[thomcc]

Yes I am coming to realize that. Is there any way around this issue?

No. See rust-lang/rfcs#3343 (comment) for an example of why, although this probably does not apply to Vec (that said, I am not in favor of this method)

[AnthonyMikh]

This API would be more useful if it returned a mutable reference. Prior art: Option::insert, Option::get_or_insert, Option::get_or_insert_with, as well as Entry::insert both for HashMap and BTreeMap.

[m-ou-se]

This doesn't seem ready. Closing this.