<div dir="ltr">RE: map etc. returning Array<div><br></div><div>You could currently return AnyCollection though, and that would then let Optional.map also return AnyCollection.</div><div><br></div><div>There is also talk in completing generics so that map could return Any<CollectionType where Element == Element> which would be even better than AnyCollection since a wrapper is removed.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"> -- Howard.<br></div></div>
<br><div class="gmail_quote">On 15 March 2016 at 12:29, Dmitri Gribenko via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Mar 14, 2016 at 5:51 PM, <<a href="mailto:davesweeris@mac.com">davesweeris@mac.com</a>> wrote:<br>
><br>
> On Mar 14, 2016, at 5:51 PM, Dmitri Gribenko via swift-evolution<br>
> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> Optional.map returns an Optional.<br>
><br>
> Array.map returns an Array.<br>
> Set.map returns an Array.<br>
> <any other collection>.map returns an Array.<br>
><br>
> I can't say that it is not valid to think about an Optional as a tiny<br>
> collection, but as implemented in Swift, .map() does objectively<br>
> behave differently...<br>
><br>
> That behavior is, at least partially, because protocols don’t currently<br>
> support this:<br>
> protocol CollectionType {<br>
> typealias T<br>
> func map<U>(transform: T->U) -> Self<U> // error: Cannot specialize<br>
> non-generic type 'Self'<br>
> }<br>
<br>
</span>This feature is called higher-kinded types, and it is not planned for<br>
design or implementation in the near future.<br>
<span class=""><br>
> I *think* I remember reading on here somewhere that the intent is to change<br>
> map and flatMap to return “Self<U>" pretty much as soon as the language<br>
> supports it.<br>
<br>
</span>As a standard library engineer I can with certainty that this is not<br>
the plan. We like the current formulation of map() that returns an<br>
Array.<br>
<br>
<a href="https://github.com/apple/swift/blob/master/docs/StdlibRationales.rst#high-order-functions-on-collections-return-arrays" rel="noreferrer" target="_blank">https://github.com/apple/swift/blob/master/docs/StdlibRationales.rst#high-order-functions-on-collections-return-arrays</a><br>
<br>
I don't think that having HKTs in the language would change the rationale.<br>
<div class="HOEnZb"><div class="h5"><br>
Dmitri<br>
<br>
--<br>
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br>
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>>*/<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>