<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>In the Smalltalk projects I worked on, we defined a method #collect:as: on Collection which allowed to pass the desired type of the result container and #collect:into: where a collection to be extended by the mapped element would be passed (Smalltalk uses the name #collect: instead of map).</div><div><br></div><div>-Thorsten </div><div><br></div><div><br>Am 21.03.2016 um 07:01 schrieb David Waite via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">I tend to look at Sequence.map (and the like) as an optimized shortcut for</div><div class=""><br class=""></div><div class="">sequence.lazy.map(mappingFn).array</div><div class=""><br class=""></div><div class="">and where array, count maxElement, etc are optimized shortcuts for reductions</div><div class=""><br class=""></div><div class="">In that light, I don’t know if other collection types are needed for optimized forms. I might prefer promoting the use of reductions instead.</div><div class=""><br class=""></div><div class="">For instance, imagine I have a Set of employees, and I map based on wage. I want the flexibility for the behavior to be:</div><div class="">- Create a new Set, collapsing duplicate wages</div><div class="">- Create a new Array, allowing for duplicate wages</div><div class="">- Create a new Set, failing if two employees have the same wage (for some definition of failing)</div><div class="">- something else</div><div class=""><br class=""></div><div class="">examples of promoting the use of reductions would be supporting mutable reduction, and possibly having a protocol for reducers as types (example that springs to mind is java’s stream Collector)</div><div class=""><br class=""></div><div class="">-DW</div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 20, 2016, at 10:04 PM, Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">RE: map etc. returning Array<div class=""><br class=""></div><div class="">You could currently return AnyCollection though, and that would then let Optional.map also return AnyCollection.</div><div class=""><br class=""></div><div class="">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" class=""><div class=""><div class="gmail_signature"> -- Howard.<br class=""></div></div>
<br class=""><div class="gmail_quote">On 15 March 2016 at 12:29, Dmitri Gribenko via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><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" class="">davesweeris@mac.com</a>> wrote:<br class="">
><br class="">
> On Mar 14, 2016, at 5:51 PM, Dmitri Gribenko via swift-evolution<br class="">
> <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> Optional.map returns an Optional.<br class="">
><br class="">
> Array.map returns an Array.<br class="">
> Set.map returns an Array.<br class="">
> <any other collection>.map returns an Array.<br class="">
><br class="">
> I can't say that it is not valid to think about an Optional as a tiny<br class="">
> collection, but as implemented in Swift, .map() does objectively<br class="">
> behave differently...<br class="">
><br class="">
> That behavior is, at least partially, because protocols don’t currently<br class="">
> support this:<br class="">
> protocol CollectionType {<br class="">
> typealias T<br class="">
> func map<U>(transform: T->U) -> Self<U> // error: Cannot specialize<br class="">
> non-generic type 'Self'<br class="">
> }<br class="">
<br class="">
</span>This feature is called higher-kinded types, and it is not planned for<br class="">
design or implementation in the near future.<br class="">
<span class=""><br class="">
> I *think* I remember reading on here somewhere that the intent is to change<br class="">
> map and flatMap to return “Self<U>" pretty much as soon as the language<br class="">
> supports it.<br class="">
<br class="">
</span>As a standard library engineer I can with certainty that this is not<br class="">
the plan. We like the current formulation of map() that returns an<br class="">
Array.<br class="">
<br class="">
<a href="https://github.com/apple/swift/blob/master/docs/StdlibRationales.rst#high-order-functions-on-collections-return-arrays" rel="noreferrer" target="_blank" class="">https://github.com/apple/swift/blob/master/docs/StdlibRationales.rst#high-order-functions-on-collections-return-arrays</a><br class="">
<br class="">
I don't think that having HKTs in the language would change the rationale.<br class="">
<div class="HOEnZb"><div class="h5"><br class="">
Dmitri<br class="">
<br class="">
--<br class="">
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br class="">
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" class="">gribozavr@gmail.com</a>>*/<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>