I'm actually starting to warm up to this idea although I'm still not a big fan of how loose its guarantees are. I do agree that it can be hard to tell which elements you're borrowing in a given function without looking through the entire thing. This is a big problem for crate authors since they risk borrowing context accidentally and unexpectedly introducing backwards compatibility errors. Perhaps it would be a good idea to be able to mark a function as not being able to borrow anything from its parent other than the contextual elements explicitly listed? AuToken can technically do that already with the unsizing restrictions but those are potentially being removed so we'd need to find a way to enshrine this as an official part of the proposal.
Perhaps a #[borrows(A, B, C)] directive would work? I was thinking of something like this:
#[borrows(MyCx)]
pub fn my_lib_api() {
inner_func();
}
fn inner_func() {
inner_func();
}
fn innerer_func() {
// This works because, one of its callers, `my_lib_api`, explicitly allow-lists the component.
cap!(mut MyCx).do_something();
// This, however, would not work and we'd see an error telling us that we might need to extend
// `my_lib_api`'s signature to reflect this new required context element.
}
To encourage users to actually use this feature, I was thinking of defining a warn-by-default lint for publicly visible functions which omit this attribute. I don't want to make it a hard error since users might want to prototype their crate first before settling on a final set of contextual requirements.
Thoughts?