Blog post: Contexts and capabilities in Rust

[tmandry]

@justinpombrio

Please don't call it capability .

I think the concepts are related, but I see the distinction you're making. I was considering context as well and I think I'm leaning that way now.

I think you can model capabilities using this feature, but it needs more thought around the details. jam1's post covers how these can interact with non-Copy values, and sunfishcode's post explicitly talks about how you can use this for capabilities.

@justinpombrio

It seems strange to me, though: there can only be one basic_arena at once, right?

Not necessarily. You could have an outer arena for a larger computation and create a smaller one for a sub-computation.

That said, it's still possible to use thread locals in some cases. Overriding would mean "pushing onto the stack" and then popping off again later. Care has to be taken around the design of when a context is "captured" in a value (caller does not know about it) versus "required" (caller is providing the context): how should overriding behave in this case? I've been thinking overriding should only apply in the latter case, but I'm not sure.

@justinpombrio

For making it more economical to use contexts all over the place, I imagined being able to annotate an module with a with clause, which would effectively put a with clause on every top-level function it defined. This would be useful in a big codebase where 90% of the code wants to share a s

+1. I'd like to see module-level generics one day, too. (But I don't really want to derail the thread talking about this either )

@justinpombrio

If you write context alloc: Allocator; , where Allocator is a trait, is there going to be a v-table somewhere? If so, I would think the Rusty thing to do would be to be explicit, and simply state the type of the actual value being passed around: context alloc = Box<dyn Allocator> or whatever.

Not necessarily. Consider it a hidden generic argument on any code that declares a with context with unspecified type. Even if you capture the context in a dyn value, the vtable that's already created by dyn should point to functions that already statically know the types of your context.

You could absolutely write context alloc = Box<dyn Allocator> if you wanted to.

@justinpombrio

Anyhow, I never actually wrote that post because I hadn't figured out the details, or a concrete proposal that would work. So take this all with a grain of salt. Hopefully at least useful in a brainstorming sort of way.

Thanks to you and to everyone else who has taken the time to pick this feature apart and ask questions. I haven't had time to respond to every post myself, but the other commenters have done a good job fleshing things out.