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

[Radbuglet]

@DragonDev1906

Interesting question: If the context is immutable, wouldn't a pure function still be pure, as long as you consider the context part of its input?

Right. I was just being casual with my terminology. A better way to phrase the specific thing I was trying to get at was, if I see the function call:

compute_something(param1, param2);

It's not immediately obvious whether it accesses my voxel subsystem. Likewise, I don't know whether:

do_something_with_voxels();

Accesses just the voxel data or if it also does something with the renderer.

The explicit use Voxels marker in the realms proposal fixes that.

@DragonDev1906

but if you have to - on the entire call hierarchy - explicitly mention the context in the function signature, including name and type, or a list of all functions it calls, doesn't that mean you've reinvented normal function arguments (potentially in a struct so there is only one argument)? At that point I see basically no difference to normal function arguments except a different syntax.

Not exactly because this says what it could potentially access—not what it actually accesses. That means that, within a self-contained subsystem, you can make it such that all functions share the same realm and essentially write code as you would in the original proposal without realms. Additionally, if you find that you actually need access to a peer subsystem in a given realm, you can just update the realm's definition to include that other realm like so:

// Original code:
realm Voxel

cap Foo in Voxel = SomeType;

fn do_something() use Voxel {
    Foo.do_something_else();
}

// Code after refactor
realm Voxel: SomeOtherRealm

cap Foo in Voxel = SomeType;

fn do_something() use Voxel {
    Foo.do_something_else();
    do_something_in_the_sub_realm(use SomeOtherRealm);
}