It's important to be able to customize the underestimate. For example, lazy non-random-access collections (like lazy filter or flatMap) return 0 not count (the default underestimate for collections) because lazy collections making unexpected multiple passes to compute their count can be problematic.
It has to be a customization point; it's the only Sequence method that doesn't lead (supposedly) to vending elements, and so can work with single-pass implementations.
What if we remove only Sequenceâs default implementation instead?
It seems to me that it causes a lot of conforming types to forget about it, especially when a lot of types are able to do better than 0.
Iâm not sure I follow what youâre trying to say, the typeâs designer should already know (or be warned from the protocol description) that the underestimatedCountâs getter shouldnât consume the sequence. Whether or not itâs a customization point seem irrelevant to me.
Wouldn't that cause a backwards-compatibility problem, where existing types suddenly have to implement the property?
underestimatedCount and makeIterator() are the primitive operations of Sequence; all other operations are done in terms of those two. How could underestimatedCount be implemented if it becomes non-extensible? There are no other non-consuming operations.
I think some people in this thread are using âcustomization pointâ to mean âprotocol memberâ and some people are using it to mean âprotocol member with default implementationâ.