Contexts and Capabilities in Rust (opens in new tab)

This sort of facility is the reason why C++ iostreams (technically, std::ios_base) support a primitive array type and static index allocator, via members iword/pword and xalloc. It is not often used, but where used it would be hard to do anything else.

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.

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...

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
    }

If a proc macro couldn't provide this functionality, I still think I'd prefer it being some sort of top-level attribute rather than a keyword, mostly due to the fact that it's visible without having to look into the function, which makes it easier to notice due to visual scanning or when using code folding to hide the bodies of methods by default. Obviously this is mostly a personal preference, but I have a pretty strongly but somewhat vague sentiment that all the info needed to understand the scope of a function should appear in the signature (or right above, in the case of annotations) rather than inside.

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?