[swift-evolution] Add an ifPresent function to Optional

[Thorsten Seitz]

> Am 21.03.2016 um 04:36 schrieb Ilya Belenkiy via swift-evolution <swift-evolution at swift.org>:
> 
>> * Are the current stdlib names for optional map and flatMap misleading? 
> 
> 
> It depends on the interpretation. The one that I came across in “Functional Swift” describes map and flatMap for container types that are not necessarily collections (Result is another container type that immediately comes to mind which is not a collection). Since these concepts are not specific to Swift, I think that it’s very important that Swift uses the names that are already established for these concepts.

+1
Functional concepts are a powerful thing and it would be a mistake for Swift to shy away from them or try to hide concepts like functors or monads in the async corner like Java or C# do. More and more languages embrace these concepts. Mind that I don't say that Swift should go the same road as Haskell, I think we can do many things better.

> 
>> * Are the current stdlib functions for optional closure application appropriate and sufficient?
> 
> I’d love to see what is called “ifPresent” in the subject of the thread. But I think that it should be called “apply” (https://en.wikipedia.org/wiki/Apply)

Apply is just function application without extracting the argument from its context first (or taking it out of its container if you prefer that analogy). So it would be the wrong name.

-Thorsten 


> 
>> On Mar 20, 2016, at 1:52 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Questions being raised in this discussion:
>> 
>> * Are the current stdlib names for optional map and flatMap misleading? 
>> * Are the current stdlib functions for optional closure application appropriate and sufficient?
>> 
>>     @warn_unused_result
>>     public func map<U>(@noescape f: (Wrapped) throws -> U) rethrows -> U?
>> 
>>     @warn_unused_result
>>     public func flatMap<U>(@noescape f: (Wrapped) throws -> U?) rethrows -> U?
>> 
>> Assume there could be up to three stdlib functions just for applying closures to .some-case 
>> optionals. Would they look like this?
>> 
>> public func f1<U>(@noescape f: (Wrapped) throws -> U) rethrows -> U?
>> public func f2<U>(@noescape f: (Wrapped) throws -> U!) rethrows -> U!
>> public func f3<U>(@noescape f: (Wrapped) throws -> U) rethrows -> Void
>> 
>> Right now f2/flatMap returns U?, not U or U!, and won't throw if nil, right? Should it
>> stay that way or change to something that throws and returns a guaranteed value?
>> Or maybe the current "f2" model (flatMap)  be discarded and replaced by an 
>> "ifPresent"-like Void call?
>> 
>> And regardless of which functions are included, what would the appropriate 
>> names for each function style be?
>> 
>> -- E
>> 
>>>> On Mar 20, 2016, at 11:22 AM, Andrey Tarantsov <andrey at tarantsov.com> wrote:
>>>> 
>>>> No.  My argument is that map on collections and on optionals are two
>>>> completely different things.  They unify on a level that does not
>>>> exist in Swift (higher-kinded types).
>>> 
>>> +1000.
>>> 
>>> Optional.map is already highly unfortunate. It makes optional arrays especially painful to deal with, but even in general, you can no longer glance at the code and see which parts are dealing with many items and which parts are dealing with single items.
>>> 
>>> I would definitely support renaming Optional.{map,flatMap}.
>>> 
>>> A.
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> 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/e1a415d3/attachment.html>