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 <[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
