Why does stacked borrows treat reference parameters specially?

[Storyyeller]

Why does stacked borrows treat reference parameters specially?

Naively, I would expect fn foo(x: &u8, y: &u8) and fn foo(xy: (&u8, &u8)) to be equivalent, but it appears that only in the former case are the references protected by a CallId. Is there an explanation for why it was decided to do things this way?

[bjorn3]

See #125 for why this is.

[RalfJung]

Naively, I would expect fn foo(x: &u8, y: &u8) and fn foo(xy: (&u8, &u8)) to be equivalent

Yeah, that would be nice to have, and maybe the final version of Stacked Borrows will work like this.

But this also opens a few new questions, (some of) which are discussed in more depth in #125 as @bjorn3 mentioned:

• Should we also recurse into private fields? If no, which module do we use to determine visibility? Wouldn't it be somewhat odd to be in a situation where adding pub to a field introduces UB? (It can introduce unsoundness, sure, but for UB I'd find this quite surprising.)
• What about enums? Traversing structs is fairly straight-forward, but should Stacked Borrows really be in the business of extracting references out of Option<&T> and protect/retag them when the current variant is Some?