[swift-evolution] Add an ifPresent function to Optional

[Krzysztof Siejkowski]

One important correction before we’ll start to use the Scala argument in the discussion.

In Scala, Option type *is not a collection type*. See http://www.scala-lang.org/api/2.11.8/#scala.Option

It has the usual monadic semantics (mostly known from collection types), but so does Try and Future.

It can be composed with arrays because Scala provides an implicit conversion form Option to Iterable (see http://bit.ly/1RZkXTr).
The Swift equivalent of implicit conversions is already established with special *-Convertible protocols like “ArrayLiteralConvertible” or “CustomStringConvertible”.

I believe it’s better to provide necessary Convertibles for Optional type in Swift than to make Optional conform to CollectionType. You get the benefits of being able to mix and match optionals and arrays (like for loops on optional) and avoid the drawback of loosing the readability of type hierarchy.

FWIW, I have also proposed “CustomOptionalConvertible” protocol some time ago: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000918.html, which I believe will make composing Optionals with other types even easier. 

- Krzysztof

On 21 March 2016 at 05:34:39, Howard Lovatt via swift-evolution (swift-evolution at swift.org) wrote:

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

_______________________________________________
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/adbd9fd4/attachment-0001.html>