If the refine RFC were implemented before Rust 1.0, I can't help but wonder if it would apply to associated items. Aside from the question of whether this could be retro-actively implemented (it's probably within the capabilities of the edition system, but would be a very noticeable change)...
The ability to depend on the exact value of an associated type of a trait impl (as opposed to the assoc. type's bounds) is something we take for granted but don't necessarily need in all cases. Should this remain the case?
For an Iterator, it's Item type must almost always be known. The same applies to Deref::Target. Implication: it should be possible to declare at the trait level that an associated type is #[refine].
For TryFrom::Error, the exact type might not be needed... though since this type lacks any bounds it is not the best example.
Motivation comes from CHANGE: Make `<SmallRng as SeedableRng>::Seed` the same type on 32 and 64 bit platforms · Issue #1285 · rust-random/rand · GitHub. To summarize:
SeedableRng::Seedis an associated type (with bounds) used by methodfrom_seed.rand::rngs::SmallRngis an undefined small-state RNG (implementingSeedableRngandRngCore), defined as a wrapper over some other RNG.
In the current implementation, the result is that <rand::rngs::SmallRng as SeedableRng>::Seed has different type and size depending on the platform, which is a portability hazard...
... but users should not be able to infer the exact type anyway (it should not be #[refine]).