# Blog post: Contexts and capabilities in Rust

**URL:** <https://internals.rust-lang.org/t/blog-post-contexts-and-capabilities-in-rust/15833>\
**Category:** language design\
**Created:** [December 21, 2021, 4:42pm UTC](https://internals.rust-lang.org/t/blog-post-contexts-and-capabilities-in-rust/15833 "2021-12-21T16:42:59Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![tmandry](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/tmandry/32/10617_2.png) [@tmandry](https://internals.rust-lang.org/u/tmandry)\
**Post date:** [December 21, 2021, 5:12pm UTC](https://internals.rust-lang.org/t/blog-post-contexts-and-capabilities-in-rust/15833/3 "2021-12-21T17:12:02Z")

</div>

Ah I missed that thread, thanks. It's based on an earlier version of the proposal Niko and I put up on the async fundamentals repo.

The answer might be similar to how I was planning to deal with `dyn`, which is to qualify each `dyn` with a `with` clause. I don't see why we couldn't do the same for function pointers. ~~But this naturally leads to the question of whether we need the ability to qualify _all_ types like this.~~ (EDIT: On second thought I don't think that's true, we only need to qualify `dyn` and function pointers. You couldn't construct a struct that had an unqualified fn pointer with a qualified fn pointer.)

Actually calling it would look similar to the solution for `dyn`, which could be to collapse all context into a single parameter that allows name-based lookup, or use a compiler-managed thread local. We can also use the approach used to implement `#[track_caller]` here to have reified functions with different ABIs depending on whether the caller is expecting to pass the specific context a function is expecting or just a "generic" context map.

---

_[View the full topic](https://internals.rust-lang.org/t/blog-post-contexts-and-capabilities-in-rust/15833)._