[swift-evolution] Add an ifPresent function to Optional

[David Waite]

I tend to look at Sequence.map (and the like) as an optimized shortcut for

sequence.lazy.map(mappingFn).array

and where array, count maxElement, etc are optimized shortcuts for reductions

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.

For instance, imagine I have a Set of employees, and I map based on wage. I want the flexibility for the behavior to be:
- Create a new Set, collapsing duplicate wages
- Create a new Array, allowing for duplicate wages
- Create a new Set, failing if two employees have the same wage (for some definition of failing)
- something else

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)

-DW

> On Mar 20, 2016, at 10:04 PM, Howard Lovatt via swift-evolution <swift-evolution at swift.org> wrote:
> 
> RE: map etc. returning Array
> 
> You could currently return AnyCollection though, and that would then let Optional.map also return AnyCollection.
> 
> 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.
> 
>   -- Howard.
> 
> On 15 March 2016 at 12:29, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> On Mon, Mar 14, 2016 at 5:51 PM,  <davesweeris at mac.com <mailto:davesweeris at mac.com>> wrote:
> >
> > On Mar 14, 2016, at 5:51 PM, Dmitri Gribenko via swift-evolution
> > <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >
> > Optional.map returns an Optional.
> >
> > Array.map returns an Array.
> > Set.map returns an Array.
> > <any other collection>.map returns an Array.
> >
> > I can't say that it is not valid to think about an Optional as a tiny
> > collection, but as implemented in Swift, .map() does objectively
> > behave differently...
> >
> > That behavior is, at least partially, because protocols don’t currently
> > support this:
> > protocol CollectionType {
> >     typealias T
> >     func map<U>(transform: T->U) -> Self<U> // error: Cannot specialize
> > non-generic type 'Self'
> > }
> 
> This feature is called higher-kinded types, and it is not planned for
> design or implementation in the near future.
> 
> > I *think* I remember reading on here somewhere that the intent is to change
> > map and flatMap to return “Self<U>" pretty much as soon as the language
> > supports it.
> 
> As a standard library engineer I can with certainty that this is not
> the plan.  We like the current formulation of map() that returns an
> Array.
> 
> https://github.com/apple/swift/blob/master/docs/StdlibRationales.rst#high-order-functions-on-collections-return-arrays <https://github.com/apple/swift/blob/master/docs/StdlibRationales.rst#high-order-functions-on-collections-return-arrays>
> 
> I don't think that having HKTs in the language would change the rationale.
> 
> Dmitri
> 
> --
> main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
> (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com <mailto:gribozavr at gmail.com>>*/
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160321/8552b499/attachment.html>