Note scoping differences between *x and *x.deref() , and a[b] and *a.index(b)

[dianne]

The equivalences between the overloaded operator expressions and their associated function call forms don't hold in the presence of temporary lifetime extension; this adjusts the rules accordingly and adds examples.

[dianne]

The sections on field access expressions and tuple indexing expressions may also benefit from similar examples or links to that example, in case it needs clarifying that the way they autoderef is scoped more like repeatedly applying * than repeatedly applying a deref method. The autoderef section on the field access expressions page is in line with that, but doesn't clarify. The tuple indexing expressions section doesn't account for autoderef at all, so it would need to be reworked first.

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[dianne]

@rustbot ready

I'll open a separate PR to add text for Box to the * operator expression documentation.

[ehuss]

When looking at this, we felt that this probably shouldn't be part of a note, but instead should be incorporated into the rule itself. The "is equivalent to" is not entirely true due to this exception. How about just adding this text here:

Suggested change

	For other types an index expression `a[b]` is equivalent to `*std::ops::Index::index(&a, b)`, or `*std::ops::IndexMut::index_mut(&mut a, b)` in a mutable place expression context.
	For other types an index expression `a[b]` is equivalent to `*std::ops::Index::index(&a, b)`, or `*std::ops::IndexMut::index_mut(&mut a, b)` in a mutable place expression context, except that when the index expression undergoes [temporary lifetime extension], the indexed expression `a` also has its temporary lifetime extended.

and then include the rust example as you have.

[dianne]

Seems good to me! I couldn't figure out a way to keep the link to destructors.scope.lifetime-extension.sub-expressions without it getting overly cluttered, but maybe it's fine to leave it out?

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[ehuss]

I'm curious about the thinking for hiding the "use" here? My thinking is that with it hidden it could be confusing since assigning to y isn't an error, it's not until the later use. For example, it could be:

Suggested change

	let y = &*std::ops::Index::index(&vec![()], 0); // ERROR
	# y;
	let y = &*std::ops::Index::index(&vec![()], 0);
	y; // ERROR

And to contrast in the other example, it could be:

let x = &vec![()][0];
x; // OK

Is it maybe that a bare identifier statement is unusual?

[dianne]

I was just going for stylistic consistency with the examples in https://doc.rust-lang.org/nightly/reference/destructors.html#r-destructors.scope.lifetime-extension; they also hide usages and put the ok/error comments a line early, relying on the text to clarify. There's a lot more examples there, so there may be more of an argument to made for brevity. I wouldn't be opposed to making the usages explicit here (or even there too) for clarity.

[ehuss]

Ok, I'm not going to block on that. If you (or someone else) see an improvement that could be made to all those examples, we can tackle that in a separate PR.

[ehuss]

Thanks!

View changes since this review