default iterator for geo traits

[kylebarron]

Change list

• Provided trait method for iterators
• Change required method to an unchecked version, so that the iterators can only bounds check once.
• Require Sized bound on traits
• Remove Iter associated type

I've been trying to use my incubating version of geo-traits heavily, but I haven't used the iterator methods on them (e.g. MultiPointTrait::points() returning an iterator instead of manually iterating through point(i) for 0..MultiPointTrait::num_points) because I haven't been able to reliably implement iterators on all the different structs due to lifetime issues.

I realized that maybe I could provide a default iterator for a generic "anything that implements this geo trait" and my proof of concept worked!

The changes to allow this are 1) removing the associated type for Iter, instead returning a concrete iterator struct and 2) making the trait require Sized. So my question is: are there any practical drawbacks to these two changes? Is there ever a reason to want to override the iterator type on the associated type of the trait? I've always thought of iterators as just syntactic sugar for for loops, but not sure if that's always the case. And is there ever a use case for implementing these traits on unsized objects. My hunch to both was no, but I thought people might have ideas.

[kylebarron]

Either vscode or git or github is being very naughty