Pre-pre-RFC/Working Prototype: Borrow-Aware Automated Context Passing

[Radbuglet]

These are some excellent questions!

@zackw

If a library crate exposes a realm in its public interface, does that mean that all of the parameters belonging to that realm are also part of the public interface?

No. A contextual parameter can be more private than the realm in which it's contained.

@zackw

If a library crate exposes a realm in its public interface, is it always a breaking change for the library to add a context parameter to that realm? (Obviously it has to be a breaking change at least some of the time.) What about renaming or removing context parameters?

Removing a non-public contextual parameter from the realm is a non-breaking change since external crates can't observe the change. That is, of course, unless the borrow sets of public functions also change in tandem.

Removing a public contextual parameter from a realm is a breaking change, however, since users may attempt to access that parameter using that realm.

Adding any contextual parameter (whether public or private) into a realm also isn't a breaking change by itself.

@zackw

If a library crate exposes functions that declare use of a realm, is it a breaking change for those functions to change which context parameters within the realm they actually use?

It is a breaking change to add usages on additional contextual parameters. That's why #[borrows_only] exists. It is, however, always fine to remove usages since this can only allow new code to compile that didn't compile before. You don't have to worry about inadvertently weaking these sets, though, since #[borrows_only] also defines to the actually borrowed set.

@zackw

What happens if a bind expression doesn't provide values for all of the context parameters that are actually used by the functions that are called within the bind block? (Clearly this should be an error; can we make it always be a compile-time error, or are there situations where it has to be reported at runtime?)

This is always a compile time error—just as it was in the prototype AuToken.

If parameters which aren't actually used are not supplied, it's not an error.

@zackw

What happens if a bind expression does provide values for all the parameters that are actually used, but not other context parameters associated with the realms declared by the functions that are called? (Before you say "of course this is also a compile time error", think about the implications for your answers to (2) and (3).)

Yes. Changing actual borrow sets has to be a breaking change anyways so we might as well permit users to provide partial context.

Ah, I see why you asked additions to and removals from existing realms. Yes, my answers to those two questions still hold.

@zackw

Do the answers to (4) and (5) change if the call tree crosses crate boundaries?

Nope! Even with the AuToken prototype, I tried my hardest to keep behavior consistent between inter-crate and intra-crate scenarios.

The only exception is that you can't define new context parameters in realms defined by an upstream crate since there really isn't a reason to do that. Also, I think I'm going to adopt the new realm definition syntax you proposed to avoid this problem entirely.

@zackw

I don't like "realms define which context elements a function is permitted to borrow—not which elements it actually borrows." I think each context-using function, public or private, should be required to declare in its signature which elements it actually borrows.

Requiring this would break the bounded refactors principle. But, yes, users are encouraged to explicitly declare actual borrow sets for functions in their public interface by a warn-by-default rustc lint.

@zackw

For similar reasons, I think the use <realm> parameter "annotation" to calls to context-using functions should be mandatory for all callsites.

There's a lint force this. It's not on by default because I've heard opinions that other users who don't want to have to use the annotation. This is probably going to be a source of bike-shedding.

@zackw

I found the part of the RFC about generics to be mostly incomprehensible. It might make more sense to someone who's more deeply familiar with the details of Rust generics, but please think hard about how to explain it better.

Thanks for the feedback! I was under the impression that the rules about generics would be intuitive since they're mostly defined by what the feature doesn't support. Are there specific things that are confusing or is it just generally difficult to follow?

@zackw

I think the restrictions that trait functions cannot consume context parameters, and that context-using functions cannot be converted to function pointers, are likely to be troublesome. Please also think about how these restrictions can be lifted.

It isn't supported because it creates a lot of hazards for semantic versioning. See the "semantics of generics" section of the AuToken README and my first design comment in this thread for details on how I got to this rule-set.

@zackw

Relatedly, please think about what it would take to be able to supply context parameters to closures.

To pass context parameters to closures, so long as the closure does not have to live for 'static, you can do:

// Acquires a bundle with a fresh inference set.
let cx = infer_set!();

use_closure(|| {
    // Binds the bundled variables in the current function's scope.
    // The inference set is automatically extended to include everything
    // needed by this function.
    bind cx;

    ...
});

There's no way to make this work if the closure has to live for 'static, regardless of the rule-set chosen, since contextual parameters are all references.

@zackw

To have confidence in a change of this magnitude to something as basic as function calls, we need to be sure it can be implemented. Therefore, the reference section should include at least an outline of how context parameter passing will be implemented at the level of assembly language.

Sorry, I'm going to need to enlist the help of a backend person to help me answer than question.

@zackw

 realm MyRealm;
 ctx MY_CTX in MyRealm = u32;

This is not how types or has-a relationships are written anywhere else in Rust. Suggest instead

realm MyRealm {
    ctx MY_CTX: u32;
}

Good suggestion!

@zackw

 realm CompositeRealm1: MyRealm1, MyRealm2;
 realm CompositeRealm2  = MyRealm1, MyRealm2;

I do not understand whether there is a semantic difference between these. If there is a semantic difference, the syntactic difference between : and = is too small. If there is none, only one syntax should be accepted. This is also not very Rustish, I would suggest (assuming no semantic difference)

realm CompositeRealm1 {
    use MyRealm1;
    use MyRealm2;
    // possibly more `ctx` declarations here
}

These do actually have a pretty significant difference: the former syntax with the : denotes a realm that can contain context items of its own whereas the latter with the = denotes a realm that cannot contain context items of its own. This is important because, in the following example:

// Upstream crate
realm Foo;

realm Bar;

// Downstream crate
fn foo() use Foo {
    bar();
}

fn bar() use Bar {
    foo();
}

It's desirable that Foo and Bar unify by name rather than by their sets of contextual parameters since, otherwise, adding any context becomes a breaking change!

However, sometimes, you do actually just want to refer to the union of realms Foo and Bar without having to write that every single time. That's why aliases exist:

realm Foo;
realm Bar;

realm MyAlias = Foo, Bar;

Realm aliases can't have context parameters of their own since it's unclear what that means.

I think we can keep the = syntax so long as we use the...

realm RealmAlias = Foo, Bar;

realm CompositeRealm1 {
    use MyRealm1;
    use MyRealm2;
    // possibly more `ctx` declarations here
}

...syntax you recommended.

@zackw

bind ( ... ) { ... }

For consistency with the rest of the language, the parentheses should be dropped.

Good suggestion. I think I updated it for bundle binding syntax but forgot to update it for individual context parameter binding.