Notes on partial borrows

[Jules-Bertholet]

@CAD97

Could this potentially solve the &mut T -> &T “borrow downgrade” case as well?

I very much hope so! Though the scheme I've described is insufficiently general to handle all cases of this. For example, fn frob<'a: 'b, 'b>(&<'b mut x, 'a z> self) -> &'a u32 would have only the shared borrow persist past the end of the function, but mutable access to z would be forbidden within the function. To fully address all cases, you would want a view like &<'b mut 'a x> Foo, where the reference can access Foo for a length of 'a but that access is mutable only for the length of 'b.

@CAD97

Just to note, “enum variants as types” is quite similar to views as types. You can almost model enum variant types as view types, where the view is the fields of the variant; the limiting factor is the special handling of the virtual discriminant field.

Now I'm wondering, would it make sense to have a view type that grants access to fields in several variants of an enum, conditional on the enum being in that variant? All such view references would have a read view of the discriminant (and would thus conflict with a full &mut, which would be the only way to get write access to the discriminant). I think the aliasing model would break this, but maybe I'm wrong?

@CAD97

self methods that only consume a subset of fields

Consuming something means assuming responsibility for dropping it—which, as you note, means that a by-value view type would need to be invariant in the view. This makes them useless for refining existing API contracts. Given that fact, I struggle to see a use-case.

@CAD97

impl applicability

Actually, I think reference views run into none of the problems that pattern types have here.

• View references, despite their subtyping relationships, have unique TypeIds. This means we can allow writing distinct impls for different views of the same type without any soundness issues. HRTB subtyping already works like this (with a FCW, but there's no remaining unsoundness).
• As you say, view references are supertypes of the standard references. This means, among other things, that implementing most of the standard traits for them (Eq, Debug etc) makes very little sense. Non-mut view references would need Copy and Clone impls, and Send/Sync would also need to be properly handled, but I think that more or less covers it.

@CAD97

It's also probably worthwhile to mention how view restrictions differ from pattern restrictions, and how we'll differentiate the two.

Pattern restrictions go on the type, view restrictions go (I propose) on the reference. This distinct placement makes them easy to tell apart: &<view> Type is pattern.