I find it too magical to be necessary, but I can see how it might be useful. This can be achieved with a wrapper, but will then require you to wrap every future, which is not too convenient
Other languages have ended up introducing it out of practical necessity, e.g. Go’s contexts, JS execution contexts. Pick your poison, although I expect Rust’s general minimal approach will leave it as extra parameters, Go-style.
It’s not about magic, it’s just not how the abstraction works.
Let’s have a concrete example, poem::web::Data utilizes opentelemetry::context::FutureExt which has the trait methods with_context() and with_current_context(). But where is the data/context actually stored? In the WithContext struct of course. Because there is no such a thing as pinning (meta)data to a trait.
Rust doesn’t do implicit transparent structs. The FutureExt trait methods return a wrapper struct WithContext which is where the data (T) and the context are stored. One method takes context directly from an argument, the other clones one from a thread local. Data can’t hang in thin air to be attached to a triat. This also shows that the abstraction you (presumably) were asking about is both possible and already exists.
Forcing a context on all T: Future types would make the abstraction non-zero-cost in any case.
you know
Futureis a trait, right?Yes, and? It defines the API all the runtimes conform to.
Stating the obvious: a trait is type class you implement for types. It’s not something you can “pin metadata” (or any data) to.
It’s an API, if you add methods to it then the implementations will support that. That is in fact the entire point of a trait.
struct SomeFuture; impl Future for SomeFuture { // .... }where are you going to “pin metadata”?
I think, they mean:
pub trait Future { // .... fn put_metadata(...); fn get_metadata(...); }I find it too magical to be necessary, but I can see how it might be useful. This can be achieved with a wrapper, but will then require you to wrap every future, which is not too convenient
Other languages have ended up introducing it out of practical necessity, e.g. Go’s contexts, JS execution contexts. Pick your poison, although I expect Rust’s general minimal approach will leave it as extra parameters, Go-style.
It’s not about magic, it’s just not how the abstraction works.
Let’s have a concrete example, poem::web::Data utilizes opentelemetry::context::FutureExt which has the trait methods
with_context()andwith_current_context(). But where is the data/context actually stored? In theWithContextstruct of course. Because there is no such a thing as pinning (meta)data to a trait.@[email protected] ^^
You do realize FutureExt is a trait right? That’s literally what I’m asking for just with it baked into Future instead of FutureExt.
FutureExttrait methods return a wrapper structWithContextwhich is where the data (T) and the context are stored. One method takes context directly from an argument, the other clones one from a thread local. Data can’t hang in thin air to be attached to a triat. This also shows that the abstraction you (presumably) were asking about is both possible and already exists.T: Futuretypes would make the abstraction non-zero-cost in any case.