Idea: Add borrows_(begin/end) to enable guard-less concurrency

language design
3

Sure. Thanks for the feedback. I agree that would be more useful and expose more of the tradeoffs. I'll see if I can find/make some more compelling/realistic examples.

In the meantime, maybe I can make my strawman example more clear. Guards are pretty ubiquitous in Rust and I think the Borrows trait would give a way to bypass them in some cases. For example, here's how you'd have to interact with my "always" up-to-date lossy mpsc channel in current Rust:

fn main() {
    let (mut reader, writer) = Writer::new(0);
    
    let _ = std::thread::spawn(move || {
        let mut writer = writer;
        writer.update_value(5);
    });

    let guard =  reader.lock();
    println!("First call {:?}", guard);
    drop(guard);

    std::thread::sleep(Duration::from_millis(10));

    let guard =  reader.lock();
    println!("Second call {:?}", guard);
    drop(guard);
}

The caller has to contend with both the reader and the guard and manage both their lifetimes. I found this a bit burdensome when I first ran into it, but I have grown to appreciate it's explicitness.

However, if we had the Borrows trait this interaction could be simplified to:

fn main() {
    let (mut reader, writer) = Writer::new(0);
    let _ = std::thread::spawn(move || {
        let mut writer = writer;
        writer.update_value(5);
    });
    // borrow begins here
    println!("First call {:?}", reader);
    // borrow ends here
    
    std::thread::sleep(Duration::from_millis(10));
    
    // borrow begins here
    println!("Second call {:?}", reader);
    // borrow ends here
}

Here, the caller is able to express their desire to have the access to the data by directly asking the reader. The library author is able to trade-off explicitness about the lock in favor of a more direct interaction. This allows the caller to be able to think in terms of borrows instead having to manage guards.

For one-off situations I think an explicit guard is likely the preferred route. But for a data structure that draws significant usage within an application, eliminating the noise and overhead of guards may end up being a significant win.

Again, this is just an idea I've been noodling on, so if you want to ignore it until I flesh it out more, I'm totally fine with that. Thanks!