I don't mind
unsized_fn_params's sugar being supported, but only if done atop "owning pointers to stack-allocated/local values", which is the missing piece in the picture. Again, we don't miss it that much when we don't mind heap-allocating, but I'd find it baffling if a system programming language's answer to a problem was "too bad if you don't have an allocator around, sorry". Hence, at the very least,
unsized_rvalues (partial) support:
But the only way to achieve this is with indirection under the hood! So now the question becomes: should that indirection be exposed, or is Rust now a high-level language with runtime opaque shenanigans low-level users can't interact with? That hasn't been the choice for
Futures, despite the
async sugar, nor anything else that I know of.
Since language-provided pointers to stack-allocated/local values are, currently, called references, hence the "owning reference" shorthand I've gone with, but obviously this would not be a borrow of the value itself, only of the value's backing storage. Maybe there was some misunderstanding / terminology ambiguity there, regarding:
whilst I reckon the point of a borrow is "to give back", and thus indeed one cannot borrow a value, drop it, and not give it back (but one can, however, borrow the storage of a value, take the value out of it (or use it
in_place, e.g., dropping it), and then "give back" the (now "uninit") backing storage of that value),
I wouldn't dare speculate knowing what the "job of a reference" is, and I don't think you should either.
I can, however, mention the
FnOnce, FnMut, Fn trinity of Rust, i.e., the "consumes/can drop", "has unique access", "has shared access" trinity.
So, in the references / "pointer to locals" world, we currently have the unique access, the shared access, but not the "consume/drop" access. So there is a piece missing, there, in the full picture.
Rust may not deem it worth it to add it at this point (so we might have to wait for the language after Rust to do so), but I'd personally feel very disappointed if Rust ended up supporting
unsized_fn_params or something akin to it, as an opaque high-level blob of sugar, leaving the finer-grained shenanigans out of our reach (again, see that other mentioned post for examples where being able to talk about the lifetime of the backing storage enables writing handy and powerful abstractions, such as
dyn-by-value "middleware", which
unsized_fn_params will never be able to support, for instance).