Migrate CoordsIter::T to be an associated type. #593
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
CHANGES.md
if knowledge of this change could be valuable to users.Previously
With the previous design, this would compile:
Even though this is not what our implementations actually look like, to the compiler it's possible for there to be multiple implementations of
CoordsIter
forPolygon<f32>
.This was problematic when I started rewriting our
ExtremeIndices
trait to be generic over any type that implementsCoordsIter
:This is the compilation error:
The issue is that if someone writes this with this new
ExtremeIndices
implementation:The compiler doesn't know which implementation to choose:
impl<'a> CoordsIter<'a, f32> for Polygon<f32>
orimpl<'a> CoordsIter<'a, f64> for Polygon<f32>
.So we need a way to tell the compiler we only have one implementation of
CoordsIter
per type. The root issue being that there is a free generic parameter in theCoordsIter
definition.Now
To fix this, we will move the
T
type parameter to an associated type. Writing this would be a compiler error:This unblocks #592