I meant a reason for the other RFC, `Allow fields in traits that map to lvalues in impl’ing type´. Ideas on disjoint borrowing on custom pointer types (if required at all) fit better in a different thread.
I actually find Swift’s solution interesting (kind of like it, but would need to try it out for a verdict) but there are some crucial details. In comparison
The input of
offsetis some well-typed object (a
KeyPathfrom what I could gather) and not a string. It even has a unique expression type for its creation. It overall feels similar to a member pointer (less strictly typed than the current Rust proposal, not every member has a unique type).
offsetis a method of a generic other type which captures the base type in a type parameter and not an ad-hoc intrinsic or macro. This suggests
KeyPathare the core primitives, not
It seems that you are not supposed or at least discouraged to use the integer result of
offsetfor manual computation of say pointers to members. Rather, you can do so type-safely with the
// Mutation through the key path root[keyPath: key] = value
Introducing offset alone without similar alternatives/abstractions could be considered rash.