[swift-evolution] Add an ifPresent function to Optional

[Howard Lovatt]

RE: Iterating over Optional

A number of languages I use make their equivalent of Optional a collection
and it is a useful unification of concepts, e.g. Scala's Option type and
Matlab (everything is a matrix).

In Scala you use optionals like collections all the time, it is really
handy.

In Matlab everything is a matrix, the equivalent of nil is an empty array.
Many other Scientific languages like APL and latter versions of Fortran
have these concepts also in some form. But I am most familiar with Matlab
and will therefore stick to describing this.

The main uses in Scala and Matlab are:

  1. To chain operations together so that if an item is missing they just
return nil (empty) rather than an error, much like Obj-C does with nil.
  2. To write one version of a function that accepts a scalar and then
apply to anything, rather than have to write a version that accepts a
scalar, a version that accepts a Collection, and a version that accepts an
Optional. For example == in Swift has overloads for both Optional and
CollectionType.
  3. In collection libraries, not to have to write versions of map, etc.
that are for Collections and for Options, etc. You see this in Swift with a
version of map etc. in AnyCollectionProtocol and in Optional.

  -- Howard.

On 21 March 2016 at 14:09, Ilya Belenkiy via swift-evolution <
swift-evolution at swift.org> wrote:

> It’s a matter of interpretation:
>
> map on a container type extracts the value from the container, applies the
> function, then puts the result in the container. The container doesn’t need
> to be a collection. Same for flatMap.
>
> I think that a function like this would be useful, but I’d call it
> “apply”. Also, I think that the fact Optional is not a collection type is a
> good thing. While it can be treated as a collection of at most 1 element,
> semantically it’s not.  We don’t really iterate over all elements in an
> optional value.
>
> > On Mar 14, 2016, at 4:28 PM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >> On Mar 14, 2016, at 2:18 PM, Daniel Vollmer via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >> Hi,
> >>
> >>> On 13 Mar 2016, at 18:04, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>>
> >>> I am in favour of making optionals consistently act like 1-item-max
> collections.
> >>
> >> Why stop there? Why not make all non-optionals collections of one?
> >
> > I don't quite see what advantage would that have. Could you elaborate?
> >
> > There's precedent in map and flatMap for treating optionals this way.
> >
> >>
> >> I’m not convinced that making optionals conform to CollectionType
> actually improves matters: Yes, it may make the odd use here or there
> slightly more convenient, but at the cost of clarity IMO: Optionals have
> largely different set of concerns than collections, and having them
> suddenly inherit all CollectionType functionality and extensions doesn’t
> make their use (if it relies on them) any clearer, it obscures their
> “Optional”-ness instead.
> >>
> >>      Daniel.
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> 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/aba6718c/attachment.html>