Rust, I demand you give me dyn trait support for async traits now.

Get on your knees and pray to the Rust god

Then maybe you can have it in 1.82 or so

And just how the hell would you encode a GAT into a vtable? This isn't the language where you can just cast shit to fuck and assume it to purely be a matter of theoretical correctness. Everything is inline, therefore everything must be known at compile time.

By the way, I'm pretty sure the old async trait macro which made functions return dyn future is actually object safe, at the cost of making poll a virtual function. I suspect this is a hefty price because it's often a hot path but I'm not completely sure.

@lorentz fair enough. I have no idea about the PL theory and internals machinery to make this work. I just the compiler smart asses come up with something.

@jassole It's a tricky question. The reason rust is so fast is that most polymorphism is static, that is, most non-literal types are deduced at compile time. This enables two vital optimizations:

- everything lives on the stack by default, which is more reliably performant than promoting heap-bound values to the stack when the compiler is able

- every function call is static, which enables the vast array of optimizations familiar to C and C++ devs; inlining, CTE, all that fun stuff.

These features come and go together. If you want to forget about exact types completely in a function, you'll have to make sure that the values live in a different scope or on the heap, and you'll have to turn the calls into dynamic function calls. However, those functions probably expect the value to be available at compile time (because that's the default), so trait objects in a codebase have a sort of ripple effect where having one sometimes forces you to turn other objects into trait objects as well.

Old macro-based async traits were object safe becaue they themselves returned trait objects of Future. This is flexible and doesn't require too much thinking, but do it enough times and your code is slower than C# because the C# compiler has been designed to opportunistically promote dynamic types and lifetimes to static ones when the stars are right, whereas in Rust this is in the user's area of responsibilities.

@lorentz One thing I learnt later, or rather had the realization is move semantics is not always "moving" merely references or pointers, it's sometimes copying the entire memory holding the object to a new location and invalidating the old.

I had the idea that everything was pinned by default.

@jassole I really like how Rust's implicit moves play out with functional techniques, but for proper functional programming I'm missing an implicit version of clone for very cheap clones such as Rc, and for proper systems programming I'm missing the accurate tracking of stack space enabled by C++'s explicit moves.

Or maybe I'm just imagining things but this is the impression I got with C++.