foonathan

I'm reminded of https://www.foonathan.net/2022/08/malloc-interface/#problem-4-realloc. While initially I was skeptical of the author's criticism of C's allocation APIs, this bug seems to be one that could've been avoided by using the proposed try_expand() instead of realloc().

Of course ideally we'd move away from provenance-based UB and Rust's third-class aliased mutability, to simpler conservative aliasing semantics by default, and allow programmers to opt into non-general optimizations by manually saving unchanging values like vector::size() into locals, or have the optimizer and programmer interactively explore code invariants and optimizations, making the optimizer a performance-focused pair programmer rather than a black box.

> isn't even legit in modern C++. That's just move semantics. When you move it, it's gone at the old name.

Exactly the opposite actually.

Rust has destructive move while modern C++ has nondestructive move.

So in Rust, an object is dead after you move out of it, and any further attempts to use it are a compiler diagnosed error. In contrast, a C++ object is remains alive after the move, and further use of it isn't forbidden by the language, although some or all uses might be forbidden by the specific user provided move function - you'll have to reference the documentation for that move function to find out.

This article explains the difference well: https://www.foonathan.net/2017/09/destructive-move/

That's what everybody originally believes (me included)!

constexpr is_right_answer(int x)
{
if (x==42) return true;
else
{
std::cout <<"try again \n";
return false;
}

A function can be constexpr as long as at least one possible invocation can be compile time evaluated. In fact compilers can't generally prove that a function can't be constexpr.

I believe constinit has the semantics you want but I've yet to study it in details.

For more details see: https://www.foonathan.net/2020/10/constexpr-platform/ .

I believe programmers are still free to define specific operators in lieu of the compiler-derived ones for such cases.

I found a blog post which raised similar concerns [0], and P1185 [1] proposes some solutions. I don't know whether they made it into the standard, though.

[0]: https://foonathan.net/2018/10/spaceship-proposals/

[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1185r1.html

Sorry to be the nitpicker here, but - the best incremental improvement would probably have seen move-destruction instead of just moves, which keep the source object alive and force the allowance for a valid 'empty' or 'dummy' state.

See also:

* https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm#Alternative move designs

* https://www.foonathan.net/2017/09/destructive-move/