> Not only do neither of those actually end the lifetime of what's passed in

>For example, consider how this would be instantiated for std::vector<int>:

Great, here you go.

https://godbolt.org/z/9v66n6Ta4

And yes, the compiler will not prevent you from using this value. (clang will eventually, I think)

But clang static analyzer will happily detect it.

https://stackoverflow.com/questions/72532377/g-detect-use-af...

> Great, here you go.

As I pointed out, your drop_new is broken for copyable types. For example, consider std::array:

    auto w = std::array<int, 3>{0, 1, 2};
    drop_new(std::move(w));
    std::cerr << w[0] << ", " << w[1] << ", " << w[2] << '\n';

This prints "0, 1, 2". Rust's drop() doesn't suffer from this flaw.

> And yes, the compiler will not prevent you from using this value.

Yes, that is the point!

This bit:

    std::vector<int> vec {1, 2, 3};
    drop_new(std::move(vec));
    std::cerr << vec.size() << " <- ?\n";

Simply does not compile in Rust [0]:

    let vec = vec![1, 2, 3];
    drop(vec);
    println!("{0} <- ?", vec.len()); // error[E0382]: borrow of moved value: `vec`

[0]: https://rust.godbolt.org/z/GjcMYnEzq

> But clang static analyzer will happily detect it.

One problem is that you're not guaranteed to catch it, similarly to why static analyzers aren't guaranteed to catch use-after-frees.

I'm not sure why you keep posting snippets demonstrating C++ rvalue references. We all know what those are, and it's not what we're talking about.

We're talking about how the rust compiler uses move semantics to prevent you from using the moved-from value, such that code like this will not compile:

    let f = Foo::new();
    drop(f);
    f.foo(); // Error: use of moved value

C++'s move semantics do not prevent you from using f after you've moved it. On the contrary, it's intentionally allowed. It's not undefined behavior either, it's "unspecified" behavior, which means "behavior, for a well-formed program construct and correct data, that depends on the implementation". This simply means that it's up to the individual type to decide what happens when a value is moved from. (A string becomes an empty string, for instance, or a vector becomes and empty vector.)

Rust's move semantics mean:

- You don't write a move constructor

- Moves are just memcpy

- The compiler enforces the old value can't be used any more

C++'s move semantics mean:

- You must write a move constructor (rvalue reference constructor)

- Moves are arbitrary code

- The language explicitly allows the moved-from value to continue to be used

That there are certain linter-style tools like clang-tidy which can be configured to warn on using moved-from values is irrelevant: The standard explicitly allows it. It's personal preference whether you should make a habit of using moved-from values in your codebase, which is why this will only ever be a linter thing. The C++ standard would have to completely change its mind and retcon moves to mean something different, if they ever wanted to change this.

Now, the beginning of this thread was someone saying "Rust is basically the wanted fixes to C++ that C++ itself could never adopt for legacy reasons". Then you came back with "I agree with your point except for the 'never' qualifier", implying C++ will eventually support Rust's ideas. But move semantics in C++ are precisely the opposite of those in Rust, because rust-style semantics were deemed impossible to implement in C++, even though it's what people actually wanted at the time. So I think it's fair to say C++ will "never" get Rust-style move semantics.