← Back to context

Comment by AlotOfReading

6 hours ago 

    I've occasionally contemplated whether Rust would benefit from another flavor of reference: no-access.

Most of the uses for this I can think of are best solved by opaque pointers for FFI. Having a rust-native reference just seems incongruous. Like, does it have size and alignment info? How would it interact with NLL? The only way I can imagine it working is if it extended referent lifetime throughout the lexical lifetime of the reference, but that defeats the purpose of NLL.

Rust solves a similar problem in closures with unique immutable references, but they're not quite the same.

4 comments

AlotOfReading

Reply
amluto  5 hours ago

In my mind, a no-access reference would have exactly the same lifetime rules (except for the exclusivity part) as any other reference. And they'd have the same size and lifetime rules.

Unsafe Rust could promote a no-access reference to a shared or a mutable reference, and the unsafe code would be responsible for not violating exclusivity rules but would have a guarantee that the referent actually exists. Using unsafe code to create a no-access reference to a nonexistent object or to a misaligned object would be UB.

Safe code could convert the other way:

    let a: &mut u32 = ...;
    let b: &noaccess u32 = a;
    let c: &u32 = ...;
    let d: &noaccess u32 = c;

This is not an entirely serious proposal.

  • AlotOfReading  4 hours ago

    Under NLL, reference lifetime is defined by the places where the reference is used, and noaccess types can't be used. So then reference lifetime has to devolve to the spans where the reference is live, which is only defined lexically.

    So for example:

        let mut data = vec!['a', 'b', 'c'];
    let b: &noaccess [char] = &data[..];
    data.push('d'); // Does this error?

    Hence the question

    • amluto  3 hours ago

      Aha, gotcha. I assume that any such reference would either do nothing or would be used by unsafe code (presumably by conversion through a raw pointer but maybe direct unsafe conversion to regular references could also be allowed).

      Your example is sneaky, though. Lifetime issues aside (suppose the next line of code uses b), that’s a noaccess reference to memory (an object? a place? I’m not sure what the current term is) that is only guaranteed to exist so long as data is not mutated. So the code with a subsequent use of data would error.

      But if it were instead:

          let b: &noaccess = data;

      Then it would not error.

  • zozbot234  3 hours ago

    It may be interesting to focus on how exactly these planned "no-access" references would differ from raw pointers? Access through raw pointers is an unsafe operation already.