<div dir="ltr"><div class="gmail_extra">Another possibility is to make “map” generic on the return type, something like:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra"><div class="gmail_extra">extension Collection {</div><div class="gmail_extra">    func map&lt;T: RangeReplaceableCollection&gt; (transform: (Iterator.Element) throws -&gt; T.Iterator.Element) rethrows -&gt; T {</div><div class="gmail_extra">        var result = T()</div><div class="gmail_extra">        for e in self { try result.append(transform(e)) }</div><div class="gmail_extra">        return result</div><div class="gmail_extra">    }</div><div class="gmail_extra">}</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">That way the user can choose what type they want. And since there is also a more-specific implementation returning an Array, that is what you’ll get if context does not constrain the type, so existing code will still work the same.</div><div class="gmail_extra"><br></div><div class="gmail_extra">We could do the same for “filter”, in which case the current proposal would just change what the default type is. So…what I’m talking about here would be purely additive and can happen later.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In any case, I do like the idea being proposed in SE–0174. If I have a collection and I filter it down, it makes sense to still be the same kind of collection. So, +1 from me.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Nevin</div></div></div>