I realized that, in my proposal, there's a potentially pretty confusing
asymmetry of what `stable` means. In the trait definition:
pub trait Mul<RHS, Result> {
fn mul(stable self, rhs: &RHS) -> Result;
}
...the keyword `stable` means that however the type which implements this trait
decides to pass `self` to `mul`, it must be guaranteed that the caller of `mul`
won't be able to observe the variable passed in as `self` being modified by
this call to `mul`. Also, a trait function that has at least one argument
marked as `stable` wouldn't be allowed to have a provided (default) definition,
because its signature doesn't say how that `stable` argument should be passed
in.
But on the actual implementation, like here:
impl<T: Clone, RHS, Result> Mul<RHS, Result> for T {
fn mul(stable self, rhs: &RHS) -> Result { ... }
}
...the keyword `stable` means that the variable which the caller of `mul`
passes in as the `self` argument will be implicitly cloned before it's passed
in if it is necessary to do so in order to ensure that the caller of `mul`
won't see that variable modified by `mul`. Static analysis will be used by the
compiler to determine when this implicit cloning can be omitted (it may
potentially be omitted due to the caller not observing the state of the passed
in variable after the function call and (possibly) before the variable getting
assigned a new value).
Perhaps another keyword would be needed for this second meaning of `stable`,
since it's completely different from the meaning of `stable` in trait
functions. Maybe something like `cloned`.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
