Contexts and Capabilities in Rust(tmandry.gitlab.io)
tmandry.gitlab.io
Contexts and Capabilities in Rust
https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capabilities/
5 comments
[deleted]
This proposal addresses a problem that I have faced all the time. I used to use Golang before Rust, Golang uses `context` package for this, and I have created `In` objects to emulate context. Consider this code[1], I pass it all over the place. I never liked it, it made function signatures complex, and did not always solve it, I had to keep track of more than one "context" types as different parts of code need different capabilities.
So I am glad people are working on it. I also find the solution quite ingenious.
The main concern that came to my mind was aliasing. This is like "spooky argument at a distance" kind of thing happening, and how do I "rename" these arguments in transit?
Say I am going to call two methods, both of them require different context data but with same "thing", eg say I want to implement a custom deserialiser that deserialises into same type, `Vec<String>`, but instead of allocating new ones I want to deserialise them into two different pre allocated buffers which I want to pass as context. But each call must get a different buffer.
Of course things would be easy if they were clear different `with` clauses, but if they overlap then I am not sure.
[1]: https://github.com/FifthTry/realm/blob/master/src/urls.rs#L1...
So I am glad people are working on it. I also find the solution quite ingenious.
The main concern that came to my mind was aliasing. This is like "spooky argument at a distance" kind of thing happening, and how do I "rename" these arguments in transit?
Say I am going to call two methods, both of them require different context data but with same "thing", eg say I want to implement a custom deserialiser that deserialises into same type, `Vec<String>`, but instead of allocating new ones I want to deserialise them into two different pre allocated buffers which I want to pass as context. But each call must get a different buffer.
Of course things would be easy if they were clear different `with` clauses, but if they overlap then I am not sure.
[1]: https://github.com/FifthTry/realm/blob/master/src/urls.rs#L1...
I might just not be understanding what's special about this keyword, but my instinct when I see this sort of thing is to wonder if a proc macro could get us most of the way there. Obviously that isn't possible in some cases, and extra syntax is needed (e.g. the `await` keyword), but this at least feels like something that syntax-wise would probably fit pretty well as an annotation on a function, e.g.
#[context = "foo"]
fn bar() {
foo.something
}
A few thoughts:
* I strongly recommend to comparing against Racket's parameters which approach the same problem.
* It's a little weird that the solution to needing to repetitively pass arguments requires you to write a declaration that is just as much work as declaring a regular argument. You still have at the call sites, but meh.
* "Has zero runtime overhead; it compiles down to the code you would write anyway." My code would use global variables to avoid wasting registers to pass arguments that are used everywhere. But I'm guessing the code assumed here is the kind bloating every function call with more arguments? How does this look when Rust exposes a C ABI function with a with clause?
* I strongly recommend to comparing against Racket's parameters which approach the same problem.
* It's a little weird that the solution to needing to repetitively pass arguments requires you to write a declaration that is just as much work as declaring a regular argument. You still have at the call sites, but meh.
* "Has zero runtime overhead; it compiles down to the code you would write anyway." My code would use global variables to avoid wasting registers to pass arguments that are used everywhere. But I'm guessing the code assumed here is the kind bloating every function call with more arguments? How does this look when Rust exposes a C ABI function with a with clause?
https://en.cppreference.com/w/cpp/io/ios_base
It is quite common for a stream object to thread a call chain from top to bottom, for independent reasons. So, ability to stick on other context has saved bacon fairly often, over the decades.