<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">One important correction before we’ll start to use the Scala argument in the discussion.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">In Scala, Option type *is not a collection type*. See <a href="http://www.scala-lang.org/api/2.11.8/#scala.Option">http://www.scala-lang.org/api/2.11.8/#scala.Option</a></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">It has the usual monadic semantics (mostly known from collection types), but so does Try and Future.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">It can be composed with arrays because Scala provides an implicit conversion form Option to Iterable (see <a href="http://bit.ly/1RZkXTr">http://bit.ly/1RZkXTr</a>).</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">The Swift equivalent of implicit conversions is already established with special *-Convertible protocols like “ArrayLiteralConvertible” or “CustomStringConvertible”.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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.</div> <div><br></div>FWIW, I have also proposed “CustomOptionalConvertible” protocol some time ago: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000918.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000918.html</a>, which I believe will make composing Optionals with other types even easier. <div><br></div><div>- Krzysztof<br> <div id="bloop_sign_1458535953458781952" class="bloop_sign"></div> <br><p class="airmail_on">On 21 March 2016 at 05:34:39, Howard Lovatt via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
<div dir="ltr">RE: Iterating over Optional
<div><br></div>
<div>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).</div>
<div><br></div>
<div>In Scala you use optionals like collections all the time, it
is really handy.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>The main uses in Scala and Matlab are:</div>
<div><br></div>
<div> 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.</div>
<div> 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.</div>
<div> 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.</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature"> -- Howard.<br></div>
</div>
<br>
<div class="gmail_quote">On 21 March 2016 at 14:09, Ilya Belenkiy
via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It’s a matter of interpretation:<br>
<br>
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.<br>
<br>
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.<br>
<div class="HOEnZb">
<div class="h5"><br>
> On Mar 14, 2016, at 4:28 PM, Erica Sadun via swift-evolution
<<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
wrote:<br>
><br>
><br>
>> On Mar 14, 2016, at 2:18 PM, Daniel Vollmer via
swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
wrote:<br>
>><br>
>> Hi,<br>
>><br>
>>> On 13 Mar 2016, at 18:04, Erica Sadun via
swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
wrote:<br>
>>><br>
>>> I am in favour of making optionals consistently act
like 1-item-max collections.<br>
>><br>
>> Why stop there? Why not make all non-optionals collections
of one?<br>
><br>
> I don't quite see what advantage would that have. Could you
elaborate?<br>
><br>
> There's precedent in map and flatMap for treating optionals
this way.<br>
><br>
>><br>
>> 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.<br>
>><br>
>> Daniel.<br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div>
</div>
</blockquote>
</div>
<br></div>
_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></div></body></html>