fn foo(&self(bar, baz), other: &Self(bar, baz))
(from PIT thread)
One could also mimic the field access syntax:
fn foo(&self.bar, other: &Self.bar)
And for multiple fields the ‘use’ syntax:
fn foo(&self.{bar, baz}, other: &Self.{bar, baz})
One thing I’m not super clear on when it comes to this whole inter-procedural borrow checker interference with disjoint self borrows issue:
Does this typically happen when the fields being borrowed are already public? Or are they typically private?
Because if they’re private, then fn foo(&self.{bar, baz}) is solving the problem by putting private fields into your public API signatures. But if they’re already public, then it seems worth the hassle of breaking up the struct into multiple public types to make an explicit commitment to their disjointness.
4 Likes
…which in turn makes me think: why don’t we just pass those fields as separate references in a similar situation? Then it wouldn’t require global reasoning (nor any modification of the language).
the PIT thread also proposed something interesting: tuple structs leak implementation details, as such maybe we should too.
No; I was trying to come up with a syntax that would fulfill @nikomatsakis's "idea that it would be nice... for the compiler to do the inference for you."
I also don't quite agree that this is "action at a distance", since the set of fields included in the view is determined where the view keyword is used. But you're right that when used in a public API, the permissible calling contexts would depend on the function implementation, so I see why you'd use that phrase.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.