Description
One thing that was rather unclear to me when reading the draft RFC is whether implementations of traits must be exclusive (e.g. you can only implement sync xor async) or whether they can be exhaustive (e.g. you can implement sync and async).
Just taking this initial example:
/// The base implementation
impl Into<Loaf> for Cat {
fn into(self) -> Loaf {
self.nap()
}
}
/// The async implementation
impl async Into<AsyncLoaf> for AsyncCat {
async fn into(self) -> AsyncLoaf {
self.async_nap().await
}
}It's not immediately clear whether this is presented as a common implementation (someone providing one implementation for each) or two options for an implementation. Note that the former case, at least in the case of const, would require RFC 3352, although there's no such precedent for async and presumably we could do this freely.
It's also worth mentioning that, in terms of effect lowering, the RFC also makes the assumption that effects are simply boolean constant generics as opposed to associated boolean constants, which also would presumably change based upon the choice here.
For something like async, having the ability to do only async or only sync is not an issue, but for const, this is relatively novel, and I'd imagine that an MVP of this would also want to consider at least const, even though stuff like try and unsafe could probably wait until later.