Rename `expose_addr` to `expose_provenance` by joboet · Pull Request #122964 · r...

expose_addr is a bad name, an address is just a number and cannot be exposed. The operation is actually about the provenance of the pointer.

This PR thus changes the name of the method to expose_provenance without changing its return type. There is sufficient precedence for returning a useful value from an operation that does something else without the name indicating such, e.g. Option::insert and MaybeUninit::write.

Returning the address is merely convenient, not a fundamental part of the operation. This is implied by the fact that integers do not have provenance since

let addr = ptr.addr();
ptr.expose_provenance();
let new = ptr::with_exposed_provenance(addr);

must behave exactly like

let addr = ptr.expose_provenance();
let new = ptr::with_exposed_provenance(addr);

as the result of ptr.expose_provenance() and ptr.addr() is the same integer. Therefore, this PR removes the #[must_use] annotation on the function and updates the documentation to reflect the important part.

An alternative name would be expose_provenance. I'm not at all opposed to that, but it makes a stronger implication than we might want that the provenance of the pointer returned by ptr::with_exposed_provenance1 is the same as that what was exposed, which is not yet specified as such IIUC. IMHO expose does not make that connection.

A previous version of this PR suggested expose as name, libs-api decided on expose_provenance to keep the symmetry with with_exposed_provenance.

CC @RalfJung
r? libs-api