Add an ifPresent function to Optional


(Lammert Westerhoff) #1

Currently the Swift Optional doesn’t have an ifPresent function.
This function is much like the map function except that the passed in function always returns Void. Almost the same can be done with the mapfunction, however the map function gives a compiler warning if it's result is unused. Also a map function can be ambiguous when there are multiple functions with the same name. The ifPresent will always pick the right function; i.e. the one returning Void and therefore is not ambiguous .

The ifPresent function is like the map function very powerful. Some examples of its usage:

let mapView: MKMapView = ... // some map view
let annotation: MKAnnotation? = ... // some optional annotation
annotation.ifPresent(mapView.addAnnotation)

I also wrote a Blog Post about this topic in which I present it as an extension of Optional with some more examples where I find it very useful: https://swiftforward.wordpress.com/2015/12/04/add-ifpresent-to-swift-optionals/

The implementation can be as simple as following:

public func ifPresent(@noescape f: (Wrapped) throws -> Void) rethrows {
   _ = try map(f)
}

···


Lammert Westerhoff


(Erica Sadun) #2

While I'm not convinced of the utility or lack thereof, wouldn't it make more sense
to extend `forEach` to support optionals in a similar way that map and flapMap
currently do rather than introduce `ifPresent`?

let y: Int? = 1
let n: Int? = nil

_ = y.map({ print($0) }) // works in current Swift
_ = n.map({ print($0) }) // ditto

y.forEach{ print($0) } // not currently a thing
n.forEach{ print($0) } // ditto

Just spitballing here.

-- E

···

On Mar 10, 2016, at 2:55 PM, Lammert Westerhoff via swift-evolution <swift-evolution@swift.org> wrote:

Currently the Swift Optional doesn’t have an ifPresent function.
This function is much like the map function except that the passed in function always returns Void. Almost the same can be done with the mapfunction, however the map function gives a compiler warning if it's result is unused. Also a map function can be ambiguous when there are multiple functions with the same name. The ifPresent will always pick the right function; i.e. the one returning Void and therefore is not ambiguous .

The ifPresent function is like the map function very powerful. Some examples of its usage:

let mapView: MKMapView = ... // some map view
let annotation: MKAnnotation? = ... // some optional annotation
annotation.ifPresent(mapView.addAnnotation)

I also wrote a Blog Post about this topic in which I present it as an extension of Optional with some more examples where I find it very useful: https://swiftforward.wordpress.com/2015/12/04/add-ifpresent-to-swift-optionals/


(Thorsten Seitz) #3

+1
ifPresent is something I've used a lot in Java/Guava.
In Smalltalk we had at:ifPresent: for dictionary lookup which could then easily be simulated by lookup followed by ifPresent.

-Thorsten

···

Am 10.03.2016 um 22:55 schrieb Lammert Westerhoff via swift-evolution <swift-evolution@swift.org>:

Currently the Swift Optional doesn’t have an ifPresent function.
This function is much like the map function except that the passed in function always returns Void. Almost the same can be done with the mapfunction, however the map function gives a compiler warning if it's result is unused. Also a map function can be ambiguous when there are multiple functions with the same name. The ifPresent will always pick the right function; i.e. the one returning Void and therefore is not ambiguous .

The ifPresent function is like the map function very powerful. Some examples of its usage:

let mapView: MKMapView = ... // some map view
let annotation: MKAnnotation? = ... // some optional annotation
annotation.ifPresent(mapView.addAnnotation)

I also wrote a Blog Post about this topic in which I present it as an extension of Optional with some more examples where I find it very useful: https://swiftforward.wordpress.com/2015/12/04/add-ifpresent-to-swift-optionals/

The implementation can be as simple as following:

public func ifPresent(@noescape f: (Wrapped) throws -> Void) rethrows {
   _ = try map(f)
}


Lammert Westerhoff
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Adam Sharp) #4

A couple other ideas:

  // Not sure about the "if" prefix, but reads nicely
  foo.ifSome { print($0) }

  // Goes with other stdlib functions accepting closures, but perhaps less clear that the closure may not execute
  foo.withSome { print($0) }

–Adam

···

On 11 Mar 2016, at 12:32 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 10, 2016, at 2:55 PM, Lammert Westerhoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Currently the Swift Optional doesn’t have an ifPresent function.
This function is much like the map function except that the passed in function always returns Void. Almost the same can be done with the mapfunction, however the map function gives a compiler warning if it's result is unused. Also a map function can be ambiguous when there are multiple functions with the same name. The ifPresent will always pick the right function; i.e. the one returning Void and therefore is not ambiguous .

The ifPresent function is like the map function very powerful. Some examples of its usage:

let mapView: MKMapView = ... // some map view
let annotation: MKAnnotation? = ... // some optional annotation
annotation.ifPresent(mapView.addAnnotation)

I also wrote a Blog Post about this topic in which I present it as an extension of Optional with some more examples where I find it very useful: https://swiftforward.wordpress.com/2015/12/04/add-ifpresent-to-swift-optionals/

While I'm not convinced of the utility or lack thereof, wouldn't it make more sense
to extend `forEach` to support optionals in a similar way that map and flapMap
currently do rather than introduce `ifPresent`?

let y: Int? = 1
let n: Int? = nil

_ = y.map({ print($0) }) // works in current Swift
_ = n.map({ print($0) }) // ditto

y.forEach{ print($0) } // not currently a thing
n.forEach{ print($0) } // ditto

Just spitballing here.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Sweeris) #5

+1.

I’d go so far as to suggest that maybe Optional should conform to CollectionProtocol, since you can pretty easily think of an Optional as a collection that can’t have more than one element.

- Dave Sweeris

···

On Mar 10, 2016, at 7:32 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

While I'm not convinced of the utility or lack thereof, wouldn't it make more sense
to extend `forEach` to support optionals in a similar way that map and flapMap
currently do rather than introduce `ifPresent`?

let y: Int? = 1
let n: Int? = nil

_ = y.map({ print($0) }) // works in current Swift
_ = n.map({ print($0) }) // ditto

y.forEach{ print($0) } // not currently a thing
n.forEach{ print($0) } // ditto

Just spitballing here.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Howard Lovatt) #6

Why not make optional a SequenceType? This works really well in Scala and
provides the desired functionality via forEach.

···

On Friday, 11 March 2016, Lammert Westerhoff via swift-evolution < swift-evolution@swift.org> wrote:

Currently the Swift Optional doesn’t have an ifPresent function.
This function is much like the map function except that the passed in
function always returns Void. Almost the same can be done with
the mapfunction, however the map function gives a compiler warning if it's
result is unused. Also a map function can be ambiguous when there are
multiple functions with the same name. The ifPresent will always pick the
right function; i.e. the one returning Void and therefore is not ambiguous .

The ifPresent function is like the map function very powerful. Some
examples of its usage:

let mapView: MKMapView = ... // some map view
let annotation: MKAnnotation? = ... // some optional annotation
annotation.ifPresent(mapView.addAnnotation)

I also wrote a Blog Post about this topic in which I present it as an
extension of Optional with some more examples where I find it very useful:
https://swiftforward.wordpress.com/2015/12/04/add-ifpresent-to-swift-optionals/

The implementation can be as simple as following:

public func ifPresent(@noescape f: (Wrapped) throws -> Void) rethrows {
   _ = try map(f)
}


Lammert Westerhoff

--
-- Howard.


(Andrey Tarantsov) #7

-0.5 in general, on the basis of me never encountering a good use case for it.

let annotation: MKAnnotation? = ... // some optional annotation
annotation.ifPresent(mapView.addAnnotation)

if let annotation = produceAnnotation() {
    mapView.addAnnotation(annotation)
}

If annotation is a property...

if let annotation = annotation {
    mapView.addAnnotation(annotation)
}

...then:

1) it's still not so bad.

2) If you have too much optional state within a class, you may want to consider extracting a helper class / struct that deals with it. IMO, too many different state lifecycles within a class is a code smell, we shouldn't mask it with ifPresent.

Would love to see some compelling real-world use cases, though — maybe I'm missing something.

A.


#8

+1, feels like a no-brainer and is a nice low-impact change.

I like it.

···

On Fri, Mar 11, 2016 at 12:14 AM, Thorsten Seitz via swift-evolution < swift-evolution@swift.org> wrote:

+1
ifPresent is something I've used a lot in Java/Guava.
In Smalltalk we had at:ifPresent: for dictionary lookup which could then
easily be simulated by lookup followed by ifPresent.

-Thorsten

Am 10.03.2016 um 22:55 schrieb Lammert Westerhoff via swift-evolution < > swift-evolution@swift.org>:

Currently the Swift Optional doesn’t have an ifPresent function.
This function is much like the map function except that the passed in
function always returns Void. Almost the same can be done with
the mapfunction, however the map function gives a compiler warning if it's
result is unused. Also a map function can be ambiguous when there are
multiple functions with the same name. The ifPresent will always pick the
right function; i.e. the one returning Void and therefore is not ambiguous .

The ifPresent function is like the map function very powerful. Some
examples of its usage:

let mapView: MKMapView = ... // some map view
let annotation: MKAnnotation? = ... // some optional annotation
annotation.ifPresent(mapView.addAnnotation)

I also wrote a Blog Post about this topic in which I present it as an
extension of Optional with some more examples where I find it very useful:
https://swiftforward.wordpress.com/2015/12/04/add-ifpresent-to-swift-optionals/

The implementation can be as simple as following:

public func ifPresent(@noescape f: (Wrapped) throws -> Void) rethrows {
   _ = try map(f)
}


Lammert Westerhoff

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Howard Lovatt) #9

@Dave, Yes, CollectionType would be better than SequenceType.

···

On Saturday, 12 March 2016, Dave via swift-evolution < swift-evolution@swift.org> wrote:

+1.

I’d go so far as to suggest that maybe Optional should conform to
CollectionProtocol, since you can pretty easily think of an Optional as a
collection that can’t have more than one element.

- Dave Sweeris

On Mar 10, 2016, at 7:32 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

While I'm not convinced of the utility or lack thereof, wouldn't it make
more sense
to extend `forEach` to support optionals in a similar way that map and
flapMap
currently do rather than introduce `ifPresent`?

let y: Int? = 1
let n: Int? = nil

_ = y.map({ print($0) }) // works in current Swift
_ = n.map({ print($0) }) // ditto

y.forEach{ print($0) } // not currently a thing
n.forEach{ print($0) } // ditto

Just spitballing here.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.


(Jordan Rose) #10

We've talked about this before, so I'm going to link directly to my (negative) response from back then: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003697.html.

(The rest of the thread is certainly also relevant, but my past opinion is still the one I most identify with here!)

Jordan

···

On Mar 11, 2016, at 12:15 , Dave via swift-evolution <swift-evolution@swift.org> wrote:

+1.

I’d go so far as to suggest that maybe Optional should conform to CollectionProtocol, since you can pretty easily think of an Optional as a collection that can’t have more than one element.

- Dave Sweeris

On Mar 10, 2016, at 7:32 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

While I'm not convinced of the utility or lack thereof, wouldn't it make more sense
to extend `forEach` to support optionals in a similar way that map and flapMap
currently do rather than introduce `ifPresent`?

let y: Int? = 1
let n: Int? = nil

_ = y.map({ print($0) }) // works in current Swift
_ = n.map({ print($0) }) // ditto

y.forEach{ print($0) } // not currently a thing
n.forEach{ print($0) } // ditto

Just spitballing here.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Adrian Kashivskyy) #11

This only solves the problem if the target function has one argument. I don't think the problem is so broad that is requires a stdlib change.

I'm -1 on this for now.

Pozdrawiam – Regards,
Adrian Kashivskyy

···

Wiadomość napisana przez Brian Pratt via swift-evolution <swift-evolution@swift.org> w dniu 11.03.2016, o godz. 16:28:

+1, feels like a no-brainer and is a nice low-impact change.

I like it.

On Fri, Mar 11, 2016 at 12:14 AM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1
ifPresent is something I've used a lot in Java/Guava.
In Smalltalk we had at:ifPresent: for dictionary lookup which could then easily be simulated by lookup followed by ifPresent.

-Thorsten

Am 10.03.2016 um 22:55 schrieb Lammert Westerhoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

Currently the Swift Optional doesn’t have an ifPresent function.
This function is much like the map function except that the passed in function always returns Void. Almost the same can be done with the mapfunction, however the map function gives a compiler warning if it's result is unused. Also a map function can be ambiguous when there are multiple functions with the same name. The ifPresent will always pick the right function; i.e. the one returning Void and therefore is not ambiguous .

The ifPresent function is like the map function very powerful. Some examples of its usage:

let mapView: MKMapView = ... // some map view
let annotation: MKAnnotation? = ... // some optional annotation
annotation.ifPresent(mapView.addAnnotation)

I also wrote a Blog Post about this topic in which I present it as an extension of Optional with some more examples where I find it very useful: https://swiftforward.wordpress.com/2015/12/04/add-ifpresent-to-swift-optionals/

The implementation can be as simple as following:

public func ifPresent(@noescape f: (Wrapped) throws -> Void) rethrows {
   _ = try map(f)
}


Lammert Westerhoff
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tikitu de Jager) #12

+1 -- I've used the "an optional is a collection with max 1 element" rhetoric to explain map/flatMap, would be great if this was true instead of "morally true".

···

@Dave,Yes, CollectionType would be better than SequenceType.

On Saturday, 12 March 2016, Dave via > swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
> +1.
>
> I’d go so far as to suggest that maybe Optional should conform to CollectionProtocol, since you can pretty easily think of an Optional as a collection that can’t have more than one element.
>
> - Dave Sweeris
>
> > On Mar 10, 2016, at 7:32 PM, Erica Sadun via > swift-evolution<swift-evolution@swift.org(javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');)>wrote:
> >
> > While I'm not convinced of the utility or lack thereof, wouldn't it make more sense
> > to extend `forEach` to support optionals in a similar way that map and flapMap
> > currently do rather than introduce `ifPresent`?
> >
> > lety:Int? =1
> > letn:Int? =nil
> >
> > _=y.map({print($0) }) // works in current Swift
> > _=n.map({print($0) }) // ditto
> >
> > y.forEach{ print($0) } // not currently a thing
> > n.forEach{ print($0) } // ditto
> >
> > Just spitballing here.
> >
> > -- E
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org(javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org'):wink:
> > https://lists.swift.org/mailman/listinfo/swift-evolution
--
-- Howard.


(Dmitri Gribenko) #13

We already considered doing this a long time ago, and we decided against it.

1. `for x in y {}` would start working everywhere because of T to T? promotion.

2. Even if we forbid that specific promotion in that context, the following

for x in optionalThing {}

is also not good if the unwrapped value is a collection. (The user
probably meant to iterate over the collection instead.)

3. Why would one want all of the collection APIs on an optional?
index(of:)? sorted()? .first/.last? Another overload of map that
returns an array?

Dmitri

···

On Fri, Mar 11, 2016 at 7:17 PM, Howard Lovatt via swift-evolution <swift-evolution@swift.org> wrote:

@Dave, Yes, CollectionType would be better than SequenceType.

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/


(Erica Sadun) #14

I suddenly have a great desire to do a pull-request on https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

-- E, who has admittedly taken on too much today

···

On Mar 14, 2016, at 9:12 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:

We've talked about this before, so I'm going to link directly to my (negative) response from back then: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003697.html.

(The rest of the thread is certainly also relevant, but my past opinion is still the one I most identify with here!)

Jordan

On Mar 11, 2016, at 12:15 , Dave via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

+1.

I’d go so far as to suggest that maybe Optional should conform to CollectionProtocol, since you can pretty easily think of an Optional as a collection that can’t have more than one element.

- Dave Sweeris

On Mar 10, 2016, at 7:32 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

While I'm not convinced of the utility or lack thereof, wouldn't it make more sense
to extend `forEach` to support optionals in a similar way that map and flapMap
currently do rather than introduce `ifPresent`?

let y: Int? = 1
let n: Int? = nil

_ = y.map({ print($0) }) // works in current Swift
_ = n.map({ print($0) }) // ditto

y.forEach{ print($0) } // not currently a thing
n.forEach{ print($0) } // ditto

Just spitballing here.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Sweeris) #15

Oh! And rereading the thread, I see that Dmitri had mentioned that as well… I must not have seen that message, because he raises some good points that I hadn’t considered. Anyway, sorry, I didn’t mean rehash something that’d already been decided.

I’m still in favor of adding ‘forEach’ over ‘ifPresent’, though… the meaning is as clear (at least to me), and it’s one less function name to remember.

- Dave Sweeris

···

On Mar 14, 2016, at 10:12 PM, Jordan Rose <jordan_rose@apple.com> wrote:

We've talked about this before, so I'm going to link directly to my (negative) response from back then: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003697.html.

(The rest of the thread is certainly also relevant, but my past opinion is still the one I most identify with here!)

Jordan

On Mar 11, 2016, at 12:15 , Dave via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

+1.

I’d go so far as to suggest that maybe Optional should conform to CollectionProtocol, since you can pretty easily think of an Optional as a collection that can’t have more than one element.

- Dave Sweeris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Kevin Lundberg) #16

+1 -- I've used the "an optional is a collection with max 1 element" rhetoric to explain map/flatMap, would be great if this was true instead of "morally true".

If optional were a sequence or collection, then could if let be considered a special case for this?:

for x in optionalX {
//...
}

I do like the idea that optional could be considered a collection, but I also worry about confusion in this case:

let a: [Int]? = [1,2,3]

for x in a {
  // a is [1,2,3], not the expected iteration of 1 through 3
}

Today this does not compile and you are forced to unwrap the optional somehow. With this change I can see that someone may unexpectedly try this and be confused as to why the type of x is not what they expect.

···

@Dave,Yes, CollectionType would be better than SequenceType.

On Saturday, 12 March 2016, Dave via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
> +1.
>
> I’d go so far as to suggest that maybe Optional should conform to CollectionProtocol, since you can pretty easily think of an Optional as a collection that can’t have more than one element.
>
> - Dave Sweeris
>
> > On Mar 10, 2016, at 7:32 PM, Erica Sadun via swift-evolution<swift-evolution@swift.org(javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');)>wrote:
> >
> > While I'm not convinced of the utility or lack thereof, wouldn't it make more sense
> > to extend `forEach` to support optionals in a similar way that map and flapMap
> > currently do rather than introduce `ifPresent`?
> >
> > lety:Int? =1
> > letn:Int? =nil
> >
> > _=y.map({print($0) }) // works in current Swift
> > _=n.map({print($0) }) // ditto
> >
> >
> > y.forEach{ print($0) } // not currently a thing
> > n.forEach{ print($0) } // ditto
> >
> > Just spitballing here.
> >
> > -- E
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org(javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org'):wink:
> > https://lists.swift.org/mailman/listinfo/swift-evolution
--
-- Howard.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Howard Lovatt) #17

I don't think:

let a: [Int]? = [1,2,3]

for x in a {
  // a is [1,2,3], not the expected iteration of 1 through 3
}

Is confusing because the type inside the loop is array. You would quickly
pick that you needed two loops:

for xs in a {
  for x in xs {
    // process x: Int
  }
}

···

On Sunday, 13 March 2016, Kevin Lundberg via swift-evolution < swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

> +1 -- I've used the "an optional is a collection with max 1 element"
rhetoric to explain map/flatMap, would be great if this was true instead of
"morally true".

If optional were a sequence or collection, then could if let be considered
a special case for this?:

for x in optionalX {
//...
}

I do like the idea that optional could be considered a collection, but I
also worry about confusion in this case:

let a: [Int]? = [1,2,3]

for x in a {
  // a is [1,2,3], not the expected iteration of 1 through 3
}

Today this does not compile and you are forced to unwrap the optional
somehow. With this change I can see that someone may unexpectedly try this
and be confused as to why the type of x is not what they expect.

>> @Dave,Yes, CollectionType would be better than SequenceType.
>>
>> On Saturday, 12 March 2016, Dave via swift-evolution< > swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
>> > +1.
>> >
>> > I’d go so far as to suggest that maybe Optional should conform to
CollectionProtocol, since you can pretty easily think of an Optional as a
collection that can’t have more than one element.
>> >
>> > - Dave Sweeris
>> >
>> > > On Mar 10, 2016, at 7:32 PM, Erica Sadun via swift-evolution< > swift-evolution@swift.org(javascript:_e(%7B%7D,'cvml',' > swift-evolution@swift.org');)>wrote:
>> > >
>> > > While I'm not convinced of the utility or lack thereof, wouldn't it
make more sense
>> > > to extend `forEach` to support optionals in a similar way that map
and flapMap
>> > > currently do rather than introduce `ifPresent`?
>> > >
>> > > lety:Int? =1
>> > > letn:Int? =nil
>> > >
>> > > _=y.map({print($0) }) // works in current Swift
>> > > _=n.map({print($0) }) // ditto
>> > >
>> > >
>> > > y.forEach{ print($0) } // not currently a thing
>> > > n.forEach{ print($0) } // ditto
>> > >
>> > > Just spitballing here.
>> > >
>> > > -- E
>> > >
>> > > _______________________________________________
>> > > swift-evolution mailing list
>> > > swift-evolution@swift.org(javascript:_e(%7B%7D,'cvml','
swift-evolution@swift.org'):wink:
>> > > https://lists.swift.org/mailman/listinfo/swift-evolution
>> --
>> -- Howard.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.


(Pierre Monod-Broca) #18

Kevin: +1

I don't know if it's relevant to put it in the standard library, but about the name : forSome would make more sense to me than forEach, or ifPresent

Pierre

···

Le 12 mars 2016 à 17:32, Kevin Lundberg via swift-evolution <swift-evolution@swift.org> a écrit :

+1 -- I've used the "an optional is a collection with max 1 element" rhetoric to explain map/flatMap, would be great if this was true instead of "morally true".

If optional were a sequence or collection, then could if let be considered a special case for this?:

for x in optionalX {
//...
}

I do like the idea that optional could be considered a collection, but I also worry about confusion in this case:

let a: [Int]? = [1,2,3]

for x in a {
// a is [1,2,3], not the expected iteration of 1 through 3
}

Today this does not compile and you are forced to unwrap the optional somehow. With this change I can see that someone may unexpectedly try this and be confused as to why the type of x is not what they expect.

@Dave,Yes, CollectionType would be better than SequenceType.

On Saturday, 12 March 2016, Dave via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:

+1.

I’d go so far as to suggest that maybe Optional should conform to CollectionProtocol, since you can pretty easily think of an Optional as a collection that can’t have more than one element.

- Dave Sweeris

On Mar 10, 2016, at 7:32 PM, Erica Sadun via swift-evolution<swift-evolution@swift.org(javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');)>wrote:

While I'm not convinced of the utility or lack thereof, wouldn't it make more sense
to extend `forEach` to support optionals in a similar way that map and flapMap
currently do rather than introduce `ifPresent`?

lety:Int? =1
letn:Int? =nil

_=y.map({print($0) }) // works in current Swift
_=n.map({print($0) }) // ditto

y.forEach{ print($0) } // not currently a thing
n.forEach{ print($0) } // ditto

Just spitballing here.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org(javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org'):wink:
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #19

`forSome` suggests that there is a filter in-place selecting some but not all of a collection's members. `forEach` better reflects that a closure is applied to each member of a collection. I am in favor of making optionals consistently act like 1-item-max collections.

-- Erica

···

On Mar 13, 2016, at 10:58 AM, Pierre Monod-Broca via swift-evolution <swift-evolution@swift.org> wrote:

Kevin: +1

I don't know if it's relevant to put it in the standard library, but about the name : forSome would make more sense to me than forEach, or ifPresent

Pierre

Le 12 mars 2016 à 17:32, Kevin Lundberg via swift-evolution <swift-evolution@swift.org> a écrit :

+1 -- I've used the "an optional is a collection with max 1 element" rhetoric to explain map/flatMap, would be great if this was true instead of "morally true".

If optional were a sequence or collection, then could if let be considered a special case for this?:

for x in optionalX {
//...
}

I do like the idea that optional could be considered a collection, but I also worry about confusion in this case:

let a: [Int]? = [1,2,3]

for x in a {
// a is [1,2,3], not the expected iteration of 1 through 3
}

Today this does not compile and you are forced to unwrap the optional somehow. With this change I can see that someone may unexpectedly try this and be confused as to why the type of x is not what they expect.

@Dave,Yes, CollectionType would be better than SequenceType.

On Saturday, 12 March 2016, Dave via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:

+1.

I’d go so far as to suggest that maybe Optional should conform to CollectionProtocol, since you can pretty easily think of an Optional as a collection that can’t have more than one element.

- Dave Sweeris

On Mar 10, 2016, at 7:32 PM, Erica Sadun via swift-evolution<swift-evolution@swift.org(javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');)>wrote:

While I'm not convinced of the utility or lack thereof, wouldn't it make more sense
to extend `forEach` to support optionals in a similar way that map and flapMap
currently do rather than introduce `ifPresent`?

lety:Int? =1
letn:Int? =nil

_=y.map({print($0) }) // works in current Swift
_=n.map({print($0) }) // ditto

y.forEach{ print($0) } // not currently a thing
n.forEach{ print($0) } // ditto

Just spitballing here.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org(javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org'):wink:
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Thorsten Seitz) #20

I agree that making Optionals conform to collection would be useful.

Nonetheless I think that ifPresent would be a useful addition because it makes the intent clearer if used on an Optional as opposed to a generic collection. Calling forEach is a little bit misleading if the static type is known to be an Optional, because it implies more that than one element might be present.

-Thorsten

···

Am 13.03.2016 um 18:04 schrieb Erica Sadun via swift-evolution <swift-evolution@swift.org>:

`forSome` suggests that there is a filter in-place selecting some but not all of a collection's members. `forEach` better reflects that a closure is applied to each member of a collection. I am in favor of making optionals consistently act like 1-item-max collections.

-- Erica

On Mar 13, 2016, at 10:58 AM, Pierre Monod-Broca via swift-evolution <swift-evolution@swift.org> wrote:

Kevin: +1

I don't know if it's relevant to put it in the standard library, but about the name : forSome would make more sense to me than forEach, or ifPresent

Pierre

Le 12 mars 2016 à 17:32, Kevin Lundberg via swift-evolution <swift-evolution@swift.org> a écrit :

+1 -- I've used the "an optional is a collection with max 1 element" rhetoric to explain map/flatMap, would be great if this was true instead of "morally true".

If optional were a sequence or collection, then could if let be considered a special case for this?:

for x in optionalX {
//...
}

I do like the idea that optional could be considered a collection, but I also worry about confusion in this case:

let a: [Int]? = [1,2,3]

for x in a {
// a is [1,2,3], not the expected iteration of 1 through 3
}

Today this does not compile and you are forced to unwrap the optional somehow. With this change I can see that someone may unexpectedly try this and be confused as to why the type of x is not what they expect.

@Dave,Yes, CollectionType would be better than SequenceType.

On Saturday, 12 March 2016, Dave via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:

+1.

I’d go so far as to suggest that maybe Optional should conform to CollectionProtocol, since you can pretty easily think of an Optional as a collection that can’t have more than one element.

- Dave Sweeris

On Mar 10, 2016, at 7:32 PM, Erica Sadun via swift-evolution<swift-evolution@swift.org(javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');)>wrote:

While I'm not convinced of the utility or lack thereof, wouldn't it make more sense
to extend `forEach` to support optionals in a similar way that map and flapMap
currently do rather than introduce `ifPresent`?

lety:Int? =1
letn:Int? =nil

_=y.map({print($0) }) // works in current Swift
_=n.map({print($0) }) // ditto

y.forEach{ print($0) } // not currently a thing
n.forEach{ print($0) } // ditto

Just spitballing here.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org(javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org'):wink:
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution