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

language design
33

Hmm, you’re the second person (along with @zackw) who has advocated for a way to summarily see the effects of context passing without reading the body of a function so I guess there’s actual demand for something like this? I do see the potential benefit of clarifying how context is threaded around since it warns people that, e.g., a pure function may not actually be pure.

I think the reason I’m not immediately on board with this feature is that, for modules where almost all functions take in context (cf: my game engine where most functions take in arenas), the list becomes quite noisy, making it difficult to spot functions that actually are of interest to the reviewer.

One way to perhaps alleviate this could be to split up context into different “realms.” For example, I could have a “voxel” realm for all my world state context and a “rendering” realm for all my rendering state. Each contextual element would live in exactly one realm. If I find myself in a context where I’m frequently using both, I could define a realm alias called “voxel rendering” defined to encompass both “voxel” and “rendering.”

A syntax like this could work:

realm Voxel;

cap MyCap1 in Voxel = MyType1;
cap MyCap2 in Voxel = MyType2;

realm Render;

cap MyCap3 in Render = MyType3;

realm VoxelRenderer = Voxel + Render;

fn foo() use VoxelRenderer {
    foo(use _);  // Shorthand for `use <set of realms in current function>`
}

fn bar() use VoxelRenderer {
    baz(use Voxel);
    maz(use Render);
    faz();
}

fn baz() use Voxel {
    // Works
    MyCap1.do_something();
    MyCap2.do_something();
    faz();

    // Doesn’t work
    // MyCap3.do_something();
    // maz(use Render);
}

fn maz() use Render {
    // (analogous to baz)
}

fn faz() {
    // Can’t use any context.
}

Realms don’t affect borrow checking; they only affect the set of components your function could theoretically borrow. In the context of checking whether a given use directive is compatible with a given function signature, equality of the two sets is duck-typed. Realms aliases can be nested and duplicates in their expanded set of base realms are perfectly acceptable.

Thoughts?

1 Like