Shorthand unwrap proposal

Evolution Discussion
1

I was wondering if people would be open to adding an unwrap method to the
Optional type, I already have a method like this which shortens code for
me.

So this:

let myReallyLongOptionalName: String? = "Hey"

if let string = myReallyLongOptionalName {
  doSomethingWith(string)
}

Could become"

let myReallyLongOptionalName: String? = "Hey"

myReallyLongOptionalName.unwrap {
  doSomethingWith($0)
}

The block would only be fired if myReallyLongOptionalName has a value.

···

*___________________________________*

*James⎥Head of Trolls*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

2

We have that, it is called '.map'.

Dmitri

···

On Thu, Jun 23, 2016 at 8:36 AM, James Campbell via swift-evolution <swift-evolution@swift.org> wrote:

I was wondering if people would be open to adding an unwrap method to the
Optional type, I already have a method like this which shortens code for
me.

So this:

let myReallyLongOptionalName: String? = "Hey"

if let string = myReallyLongOptionalName {
  doSomethingWith(string)
}

Could become"

let myReallyLongOptionalName: String? = "Hey"

myReallyLongOptionalName.unwrap {
  doSomethingWith($0)
}

--
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>*/

3

I’m a bit tore on this myself. I see the appeal, but let’s say we had such a function. If you wanted to use it with an named parameter it’d look like this:

myReallyLongOptionalName.unwrap { string in
  doSomethingWith(string)
}

And that is actually *more* characters than the current approach:

if let string = myReallyLongOptionalName {
  doSomethingWith(string)
}

However it’d be a big win especially when you can skip $0 and the braces entirely such as:

myReallyLongOptionalName.unwrap(doSomethingWith)

Of course if we were dealing with methods, you could write this like:

myReallyLongOptionalName?.doSomething()

And that is probably hard to beat.

So I think the problem really only presents itself when you have an optional that you need to unwrap and use as a parameter to something that does not take an optional.

I don’t have a solution - just trying to clarify the situation. :)

l8r
Sean

···

On Jun 23, 2016, at 10:36 AM, James Campbell via swift-evolution <swift-evolution@swift.org> wrote:

I was wondering if people would be open to adding an unwrap method to the Optional type, I already have a method like this which shortens code for me.

So this:

let myReallyLongOptionalName: String? = "Hey"

if let string = myReallyLongOptionalName {
  doSomethingWith(string)
}

Could become"

let myReallyLongOptionalName: String? = "Hey"

myReallyLongOptionalName.unwrap {
  doSomethingWith($0)
}

The block would only be fired if myReallyLongOptionalName has a value.

___________________________________

James⎥Head of Trolls

james@supmenow.com⎥supmenow.com

Sup

Runway East >

10 Finsbury Square

London

> EC2A 1AF

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

4

Map requires you to return a value you wish to map the optional to, this is
more like a forEach that only fires when the Optional is .Some

···

*___________________________________*

*James⎥Head of Trolls*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 23 June 2016 at 16:56, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Thu, Jun 23, 2016 at 8:36 AM, James Campbell via swift-evolution > <swift-evolution@swift.org> wrote:
> I was wondering if people would be open to adding an unwrap method to the
> Optional type, I already have a method like this which shortens code for
> me.
>
> So this:
>
> let myReallyLongOptionalName: String? = "Hey"
>
> if let string = myReallyLongOptionalName {
> doSomethingWith(string)
> }
>
> Could become"
>
> let myReallyLongOptionalName: String? = "Hey"
>
> myReallyLongOptionalName.unwrap {
> doSomethingWith($0)
> }

We have that, it is called '.map'.

Dmitri

--
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>*/

5

So I have a real-life situation in an application, which does what you
mention:

This code is for a camera app, on a `didSet` it removes a device if set
from the capture session, and if there is a new one set it adds it to the
capture session.

The add and remove methods indeed don't take optionals.

So this is the code before:

var audioDevice: AVCaptureDeviceInput? = nil {

        willSet {

            if let audioDevice = audioDevice {

               captureSession?.removeInput(audioDevice)

            }

        }

        didSet {

            if audioDevice = audioDevice {

               captureSession?.addInput(audioDevice)

            }

        }

    }

and after:

var audioDevice: AVCaptureDeviceInput? = nil {

        willSet {

            audioDevice.unwrap {

                self.captureSession?.removeInput($0)

            }

        }

        didSet {

            audioDevice.unwrap {

                self.captureSession?.addInput($0)

            }

        }

    }

The last two saved me a lot of typing in these cases and I feel like it is
more clear what is going on due to the `unwrap` method being clear in it's
intent and the lack of `audioDevice` being repeated multiple times.

···

*___________________________________*

*James⎥Head of Trolls*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 23 June 2016 at 17:11, Sean Heber <sean@fifthace.com> wrote:

I’m a bit tore on this myself. I see the appeal, but let’s say we had such
a function. If you wanted to use it with an named parameter it’d look like
this:

myReallyLongOptionalName.unwrap { string in
  doSomethingWith(string)
}

And that is actually *more* characters than the current approach:

if let string = myReallyLongOptionalName {
  doSomethingWith(string)
}

However it’d be a big win especially when you can skip $0 and the braces
entirely such as:

myReallyLongOptionalName.unwrap(doSomethingWith)

Of course if we were dealing with methods, you could write this like:

myReallyLongOptionalName?.doSomething()

And that is probably hard to beat.

So I think the problem really only presents itself when you have an
optional that you need to unwrap and use as a parameter to something that
does not take an optional.

I don’t have a solution - just trying to clarify the situation. :)

l8r
Sean

> On Jun 23, 2016, at 10:36 AM, James Campbell via swift-evolution < > swift-evolution@swift.org> wrote:
>
> I was wondering if people would be open to adding an unwrap method to
the Optional type, I already have a method like this which shortens code
for me.
>
> So this:
>
> let myReallyLongOptionalName: String? = "Hey"
>
> if let string = myReallyLongOptionalName {
> doSomethingWith(string)
> }
>
> Could become"
>
> let myReallyLongOptionalName: String? = "Hey"
>
> myReallyLongOptionalName.unwrap {
> doSomethingWith($0)
> }
>
> The block would only be fired if myReallyLongOptionalName has a value.
>
> ___________________________________
>
> James⎥Head of Trolls
>
> james@supmenow.com⎥supmenow.com
>
> Sup
>
> Runway East >
>
> 10 Finsbury Square
>
> London
>
> > EC2A 1AF
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

6

There was a proposal not long ago floating around that there could be if and guard that would allow something like:

guard myReallyLongOptionalName! else {
  return
}

/// Now myReallyLongOptionalName is guaranteed to be nonnull

-- OR --

if myReallyLongOptionalName! {
  doSomethingWith(myReallyLongOptionalName)
}

···

On Jun 23, 2016, at 5:36 PM, James Campbell via swift-evolution <swift-evolution@swift.org> wrote:

I was wondering if people would be open to adding an unwrap method to the Optional type, I already have a method like this which shortens code for me.

So this:

let myReallyLongOptionalName: String? = "Hey"

if let string = myReallyLongOptionalName {
  doSomethingWith(string)
}

Could become"

let myReallyLongOptionalName: String? = "Hey"

myReallyLongOptionalName.unwrap {
  doSomethingWith($0)
}

The block would only be fired if myReallyLongOptionalName has a value.

___________________________________

James⎥Head of Trolls

james@supmenow.com <mailto:james@supmenow.com>⎥supmenow.com <Supmenow.com is for sale | HugeDomains;
Sup

Runway East >

10 Finsbury Square

London

> EC2A 1AF

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

7

I would love to be able to do something like

doSomething(with: myOptional?)

which would be equivalent to

if let myValue = myOptional {
    doSomething(with: myValue)
}

But it’s been discussed here before, and I don’t think people were very enthusiastic about it.

···

I was wondering if people would be open to adding an unwrap method to the Optional type,I already have a method like this which shortens code for me.

So this:

let myReallyLongOptionalName: String? = "Hey"

if let string = myReallyLongOptionalName {
doSomethingWith(string)
}

Could become"

let myReallyLongOptionalName: String? = "Hey"

myReallyLongOptionalName.unwrap {
doSomethingWith($0)
}

The block would only be fired if myReallyLongOptionalName has a value.

___________________________________

James⎥Head of Trolls

james@supmenow.com(mailto:james@supmenow.com)⎥supmenow.com(http://supmenow.com)

Sup

Runway East

10 Finsbury Square

London

EC2A 1AF

8

This is equivalent to the “Add an ifPresent function to Optional”
suggestion made back in March.

http://thread.gmane.org/gmane.comp.lang.swift.evolution/9173

Personally I'd prefer an `ifPresent` or `foreach` method to using
`map`, as `ifPresent` or `foreach` would make it clearer to the reader
that no return value is expected or wanted from either `ifPresent` or
the block it calls.

9

I think we’d still just recommend using ‘map’ for this. The reason Collection.map and Collection.forEach are different is because we don’t promise eager and in-order evaluation for Collection.map. But Optional only executes the closure one or zero times, so there’s no ambiguity.

Jordan

···

On Jun 23, 2016, at 09:15, James Campbell via swift-evolution <swift-evolution@swift.org> wrote:

So I have a real-life situation in an application, which does what you mention:

This code is for a camera app, on a `didSet` it removes a device if set from the capture session, and if there is a new one set it adds it to the capture session.

The add and remove methods indeed don't take optionals.

So this is the code before:

var audioDevice: AVCaptureDeviceInput? = nil {

        willSet {

            if let audioDevice = audioDevice {

               captureSession?.removeInput(audioDevice)

            }

        }

        didSet {

            if audioDevice = audioDevice {

               captureSession?.addInput(audioDevice)

            }

        }

    }

and after:

var audioDevice: AVCaptureDeviceInput? = nil {

        willSet {

            audioDevice.unwrap {

                self.captureSession?.removeInput($0)

            }

        }

        didSet {

            audioDevice.unwrap {

                self.captureSession?.addInput($0)

            }

        }

    }

The last two saved me a lot of typing in these cases and I feel like it is more clear what is going on due to the `unwrap` method being clear in it's intent and the lack of `audioDevice` being repeated multiple times.

___________________________________

James⎥Head of Trolls

james@supmenow.com <mailto:james@supmenow.com>⎥supmenow.com <Supmenow.com is for sale | HugeDomains;
Sup

Runway East >

10 Finsbury Square

London

> EC2A 1AF

On 23 June 2016 at 17:11, Sean Heber <sean@fifthace.com <mailto:sean@fifthace.com>> wrote:
I’m a bit tore on this myself. I see the appeal, but let’s say we had such a function. If you wanted to use it with an named parameter it’d look like this:

myReallyLongOptionalName.unwrap { string in
  doSomethingWith(string)
}

And that is actually *more* characters than the current approach:

if let string = myReallyLongOptionalName {
  doSomethingWith(string)
}

However it’d be a big win especially when you can skip $0 and the braces entirely such as:

myReallyLongOptionalName.unwrap(doSomethingWith)

Of course if we were dealing with methods, you could write this like:

myReallyLongOptionalName?.doSomething()

And that is probably hard to beat.

So I think the problem really only presents itself when you have an optional that you need to unwrap and use as a parameter to something that does not take an optional.

I don’t have a solution - just trying to clarify the situation. :)

l8r
Sean

> On Jun 23, 2016, at 10:36 AM, James Campbell via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> I was wondering if people would be open to adding an unwrap method to the Optional type, I already have a method like this which shortens code for me.
>
> So this:
>
> let myReallyLongOptionalName: String? = "Hey"
>
> if let string = myReallyLongOptionalName {
> doSomethingWith(string)
> }
>
> Could become"
>
> let myReallyLongOptionalName: String? = "Hey"
>
> myReallyLongOptionalName.unwrap {
> doSomethingWith($0)
> }
>
> The block would only be fired if myReallyLongOptionalName has a value.
>
> ___________________________________
>
> James⎥Head of Trolls
>
> james@supmenow.com <mailto:james@supmenow.com>⎥supmenow.com <Supmenow.com is for sale | HugeDomains;
>
> Sup
>
> Runway East > >
>
> 10 Finsbury Square
>
> London
>
> > EC2A 1AF
>
> _______________________________________________
> 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

10

Do we know what happened ?

···

*___________________________________*

*James⎥Head of Trolls*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 23 June 2016 at 16:42, Charlie Monroe <charlie@charliemonroe.net> wrote:

There was a proposal not long ago floating around that there could be if
and guard that would allow something like:

guard myReallyLongOptionalName! else {
return
}

/// Now myReallyLongOptionalName is guaranteed to be nonnull

-- OR --

if myReallyLongOptionalName! {
doSomethingWith(myReallyLongOptionalName)
}

On Jun 23, 2016, at 5:36 PM, James Campbell via swift-evolution < > swift-evolution@swift.org> wrote:

I was wondering if people would be open to adding an unwrap method to the
Optional type, I already have a method like this which shortens code for
me.

So this:

let myReallyLongOptionalName: String? = "Hey"

if let string = myReallyLongOptionalName {
  doSomethingWith(string)
}

Could become"

let myReallyLongOptionalName: String? = "Hey"

myReallyLongOptionalName.unwrap {
  doSomethingWith($0)
}

The block would only be fired if myReallyLongOptionalName has a value.

*___________________________________*

*James⎥Head of Trolls*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com
<Supmenow.com is for sale | HugeDomains*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

11

So if the function I run inside of the map has a return value of Void will
that still compile ?

···

*___________________________________*

*James⎥Head of Trolls*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 23 June 2016 at 17:22, Jordan Rose <jordan_rose@apple.com> wrote:

I think we’d still just recommend using ‘map’ for this. The reason
Collection.map and Collection.forEach are different is because we don’t
promise eager and in-order evaluation for Collection.map. But Optional only
executes the closure one or zero times, so there’s no ambiguity.

Jordan

On Jun 23, 2016, at 09:15, James Campbell via swift-evolution < > swift-evolution@swift.org> wrote:

So I have a real-life situation in an application, which does what you
mention:

This code is for a camera app, on a `didSet` it removes a device if set
from the capture session, and if there is a new one set it adds it to the
capture session.

The add and remove methods indeed don't take optionals.

So this is the code before:

var audioDevice: AVCaptureDeviceInput? = nil {

        willSet {

            if let audioDevice = audioDevice {

               captureSession?.removeInput(audioDevice)

            }

        }

        didSet {

            if audioDevice = audioDevice {

               captureSession?.addInput(audioDevice)

            }

        }

    }

and after:

var audioDevice: AVCaptureDeviceInput? = nil {

        willSet {

            audioDevice.unwrap {

                self.captureSession?.removeInput($0)

            }

        }

        didSet {

            audioDevice.unwrap {

                self.captureSession?.addInput($0)

            }

        }

    }

The last two saved me a lot of typing in these cases and I feel like it is
more clear what is going on due to the `unwrap` method being clear in it's
intent and the lack of `audioDevice` being repeated multiple times.

*___________________________________*

*James⎥Head of Trolls*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com
<Supmenow.com is for sale | HugeDomains*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 23 June 2016 at 17:11, Sean Heber <sean@fifthace.com> wrote:

I’m a bit tore on this myself. I see the appeal, but let’s say we had
such a function. If you wanted to use it with an named parameter it’d look
like this:

myReallyLongOptionalName.unwrap { string in
  doSomethingWith(string)
}

And that is actually *more* characters than the current approach:

if let string = myReallyLongOptionalName {
  doSomethingWith(string)
}

However it’d be a big win especially when you can skip $0 and the braces
entirely such as:

myReallyLongOptionalName.unwrap(doSomethingWith)

Of course if we were dealing with methods, you could write this like:

myReallyLongOptionalName?.doSomething()

And that is probably hard to beat.

So I think the problem really only presents itself when you have an
optional that you need to unwrap and use as a parameter to something that
does not take an optional.

I don’t have a solution - just trying to clarify the situation. :)

l8r
Sean

> On Jun 23, 2016, at 10:36 AM, James Campbell via swift-evolution < >> swift-evolution@swift.org> wrote:
>
> I was wondering if people would be open to adding an unwrap method to
the Optional type, I already have a method like this which shortens code
for me.
>
> So this:
>
> let myReallyLongOptionalName: String? = "Hey"
>
> if let string = myReallyLongOptionalName {
> doSomethingWith(string)
> }
>
> Could become"
>
> let myReallyLongOptionalName: String? = "Hey"
>
> myReallyLongOptionalName.unwrap {
> doSomethingWith($0)
> }
>
> The block would only be fired if myReallyLongOptionalName has a value.
>
> ___________________________________
>
> James⎥Head of Trolls
>
> james@supmenow.com⎥supmenow.com
>
> Sup
>
> Runway East >
>
> 10 Finsbury Square
>
> London
>
> > EC2A 1AF
>
> _______________________________________________
> 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

12

Here is the thread:

http://thread.gmane.org/gmane.comp.lang.swift.evolution/17142

···

On Jun 23, 2016, at 6:02 PM, James Campbell <james@supmenow.com> wrote:

Do we know what happened ?

___________________________________

James⎥Head of Trolls

james@supmenow.com <mailto:james@supmenow.com>⎥supmenow.com <Supmenow.com is for sale | HugeDomains;
Sup

Runway East >

10 Finsbury Square

London

> EC2A 1AF

On 23 June 2016 at 16:42, Charlie Monroe <charlie@charliemonroe.net <mailto:charlie@charliemonroe.net>> wrote:
There was a proposal not long ago floating around that there could be if and guard that would allow something like:

guard myReallyLongOptionalName! else {
  return
}

/// Now myReallyLongOptionalName is guaranteed to be nonnull

-- OR --

if myReallyLongOptionalName! {
  doSomethingWith(myReallyLongOptionalName)
}

On Jun 23, 2016, at 5:36 PM, James Campbell via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I was wondering if people would be open to adding an unwrap method to the Optional type, I already have a method like this which shortens code for me.

So this:

let myReallyLongOptionalName: String? = "Hey"

if let string = myReallyLongOptionalName {
  doSomethingWith(string)
}

Could become"

let myReallyLongOptionalName: String? = "Hey"

myReallyLongOptionalName.unwrap {
  doSomethingWith($0)
}

The block would only be fired if myReallyLongOptionalName has a value.

___________________________________

James⎥Head of Trolls

james@supmenow.com <mailto:james@supmenow.com>⎥supmenow.com <Supmenow.com is for sale | HugeDomains;
Sup

Runway East >>

10 Finsbury Square

London

>> EC2A 1AF

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

13

I would love to be able to do something like

doSomething(with: myOptional?)

This actually looks good to me, though if I were a newcomer to the language, it would be really cryptic.

In case the function returned any value, it could become an optional, just like with try?...

I still, however, prefer the original proposal of if let myOptional! { doSomething(myOptional) }...

···

On Jun 23, 2016, at 8:45 PM, Tim Vermeulen via swift-evolution <swift-evolution@swift.org> wrote:

which would be equivalent to

if let myValue = myOptional {
   doSomething(with: myValue)
}

But it’s been discussed here before, and I don’t think people were very enthusiastic about it.

I was wondering if people would be open to adding an unwrap method to the Optional type,I already have a method like this which shortens code for me.

So this:

let myReallyLongOptionalName: String? = "Hey"

if let string = myReallyLongOptionalName {
doSomethingWith(string)
}

Could become"

let myReallyLongOptionalName: String? = "Hey"

myReallyLongOptionalName.unwrap {
doSomethingWith($0)
}

The block would only be fired if myReallyLongOptionalName has a value.

___________________________________

James⎥Head of Trolls

james@supmenow.com(mailto:james@supmenow.com)⎥supmenow.com(http://supmenow.com)

Sup

Runway East

10 Finsbury Square

London

EC2A 1AF

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

14

No, you do not need to return a value.

    q.map { print($0) }

works fine.

···

on Thu Jun 23 2016, James Campbell <swift-evolution@swift.org> wrote:

Map requires you to return a value you wish to map the optional to, this is
more like a forEach that only fires when the Optional is .Some

--
Dave

15

Yes.

Dmitri

···

On Thu, Jun 23, 2016 at 9:25 AM, James Campbell via swift-evolution <swift-evolution@swift.org> wrote:

So if the function I run inside of the map has a return value of Void will
that still compile ?

--
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>*/

16

Awesome, cheers guys!

···

*___________________________________*

*James⎥Head of Trolls*

*james@supmenow.com <james@supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On 23 June 2016 at 17:26, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Thu, Jun 23, 2016 at 9:25 AM, James Campbell via swift-evolution > <swift-evolution@swift.org> wrote:
> So if the function I run inside of the map has a return value of Void
will
> that still compile ?

Yes.

Dmitri

--
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>*/

17

You can also do something like that is ur code today:

extension Optional {
    func unwrap<T> (_ h: T -> ()) {
        switch self {
        case .Some(let w):
            if let t = w as? T { h(t) }
            break
        default:
            break;
        }
    }
}

s1.unwrap { (str:String) in
    print("NOPE") // nothing happens
}
s2.unwrap { (str:String) in
    print(":)") // prints
}

Regards
(From mobile)

···

On Jun 23, 2016, at 6:25 PM, James Campbell via swift-evolution <swift-evolution@swift.org> wrote:

So if the function I run inside of the map has a return value of Void will that still compile ?

___________________________________

James⎥Head of Trolls

james@supmenow.com⎥supmenow.com

Sup

Runway East >

10 Finsbury Square

London

> EC2A 1AF

On 23 June 2016 at 17:22, Jordan Rose <jordan_rose@apple.com> wrote:
I think we’d still just recommend using ‘map’ for this. The reason Collection.map and Collection.forEach are different is because we don’t promise eager and in-order evaluation for Collection.map. But Optional only executes the closure one or zero times, so there’s no ambiguity.

Jordan

On Jun 23, 2016, at 09:15, James Campbell via swift-evolution <swift-evolution@swift.org> wrote:

So I have a real-life situation in an application, which does what you mention:

This code is for a camera app, on a `didSet` it removes a device if set from the capture session, and if there is a new one set it adds it to the capture session.

The add and remove methods indeed don't take optionals.

So this is the code before:

var audioDevice: AVCaptureDeviceInput? = nil {

        willSet {

            if let audioDevice = audioDevice {

               captureSession?.removeInput(audioDevice)

            }

        }

        didSet {

            if audioDevice = audioDevice {

               captureSession?.addInput(audioDevice)

            }

        }

    }

and after:

var audioDevice: AVCaptureDeviceInput? = nil {

        willSet {

            audioDevice.unwrap {

                self.captureSession?.removeInput($0)

            }

        }

        didSet {

            audioDevice.unwrap {

                self.captureSession?.addInput($0)

            }

        }

    }

The last two saved me a lot of typing in these cases and I feel like it is more clear what is going on due to the `unwrap` method being clear in it's intent and the lack of `audioDevice` being repeated multiple times.

___________________________________

James⎥Head of Trolls

james@supmenow.com⎥supmenow.com

Sup

Runway East >>>

10 Finsbury Square

London

>>> EC2A 1AF

On 23 June 2016 at 17:11, Sean Heber <sean@fifthace.com> wrote:
I’m a bit tore on this myself. I see the appeal, but let’s say we had such a function. If you wanted to use it with an named parameter it’d look like this:

myReallyLongOptionalName.unwrap { string in
  doSomethingWith(string)
}

And that is actually *more* characters than the current approach:

if let string = myReallyLongOptionalName {
  doSomethingWith(string)
}

However it’d be a big win especially when you can skip $0 and the braces entirely such as:

myReallyLongOptionalName.unwrap(doSomethingWith)

Of course if we were dealing with methods, you could write this like:

myReallyLongOptionalName?.doSomething()

And that is probably hard to beat.

So I think the problem really only presents itself when you have an optional that you need to unwrap and use as a parameter to something that does not take an optional.

I don’t have a solution - just trying to clarify the situation. :)

l8r
Sean

> On Jun 23, 2016, at 10:36 AM, James Campbell via swift-evolution <swift-evolution@swift.org> wrote:
>
> I was wondering if people would be open to adding an unwrap method to the Optional type, I already have a method like this which shortens code for me.
>
> So this:
>
> let myReallyLongOptionalName: String? = "Hey"
>
> if let string = myReallyLongOptionalName {
> doSomethingWith(string)
> }
>
> Could become"
>
> let myReallyLongOptionalName: String? = "Hey"
>
> myReallyLongOptionalName.unwrap {
> doSomethingWith($0)
> }
>
> The block would only be fired if myReallyLongOptionalName has a value.
>
> ___________________________________
>
> James⎥Head of Trolls
>
> james@supmenow.com⎥supmenow.com
>
> Sup
>
> Runway East >>>> >
>
> 10 Finsbury Square
>
> London
>
> > EC2A 1AF
>
> _______________________________________________
> 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

18

Why with the exclamation mark? It suggests you’re force unwrapping something.

···

> On Jun 23, 2016, at 8:45 PM, Tim Vermeulen via swift-evolution<swift-evolution@swift.org>wrote:
>
> I would love to be able to do something like
>
> doSomething(with: myOptional?)
This actually looks good to me, though if I were a newcomer to the language, it would be really cryptic.

In case the function returned any value, it could become an optional, just like with try?...

I still, however, prefer the original proposal of if let myOptional! { doSomething(myOptional) }...

>
> which would be equivalent to
>
> if let myValue = myOptional {
> doSomething(with: myValue)
> }
>
> But it’s been discussed here before, and I don’t think people were very enthusiastic about it.
>
> > I was wondering if people would be open to adding an unwrap method to the Optional type,I already have a method like this which shortens code for me.
> >
> > So this:
> >
> > let myReallyLongOptionalName: String? = "Hey"
> >
> > if let string = myReallyLongOptionalName {
> > doSomethingWith(string)
> > }
> >
> > Could become"
> >
> > let myReallyLongOptionalName: String? = "Hey"
> >
> > myReallyLongOptionalName.unwrap {
> > doSomethingWith($0)
> > }
> >
> > The block would only be fired if myReallyLongOptionalName has a value.
> >
> >
> > ___________________________________
> >
> >
> > James⎥Head of Trolls
> >
> >
> > james@supmenow.com(mailto:james@supmenow.com)⎥supmenow.com(http://supmenow.com)
> >
> >
> > Sup
> >
> >
> > Runway East
> >
> >
> > 10 Finsbury Square
> >
> >
> > London
> >
> >
> > EC2A 1AF
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

19

Regards
(From mobile)

I would love to be able to do something like

doSomething(with: myOptional?)

This actually looks good to me, though if I were a newcomer to the language, it would be really cryptic.

In case the function returned any value, it could become an optional, just like with try?...

I still, however, prefer the original proposal of if let myOptional! { doSomething(myOptional) }...

    func doSomething<T> (with: t:T?, h: T -> ()) {
            if let t = self as? T { h(t) }
    }
extension Optional {
    func unwrap<T> (_ h: T -> ()) {
            if let t = self as? T { h(t) }
    }
}

Var s2:Sting?
s2.unwrap { (str:String) in
    print(":)")
}
doSomething(with:s2) { //same as above}

Nothing happens in both cases

···

On Jun 23, 2016, at 8:51 PM, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 23, 2016, at 8:45 PM, Tim Vermeulen via swift-evolution <swift-evolution@swift.org> wrote:

which would be equivalent to

if let myValue = myOptional {
  doSomething(with: myValue)
}

But it’s been discussed here before, and I don’t think people were very enthusiastic about it.

I was wondering if people would be open to adding an unwrap method to the Optional type,I already have a method like this which shortens code for me.

So this:

let myReallyLongOptionalName: String? = "Hey"

if let string = myReallyLongOptionalName {
doSomethingWith(string)
}

Could become"

let myReallyLongOptionalName: String? = "Hey"

myReallyLongOptionalName.unwrap {
doSomethingWith($0)
}

The block would only be fired if myReallyLongOptionalName has a value.

___________________________________

James⎥Head of Trolls

james@supmenow.com(mailto:james@supmenow.com)⎥supmenow.com(http://supmenow.com)

Sup

Runway East

10 Finsbury Square

London

EC2A 1AF

_______________________________________________
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

20

So if the function I run inside of the map has a return value of Void will
that still compile ?

Yes.

Btw, in case of

let s: String? = "hi"
s.map {print($0)}

we have
warning: result of call to 'map' is unused
s.map {print($0)}

Isn't it strange that result of call is Void, but we have a warning? Don't we need to suppress warning in this case?

Otherwise we need to write boilerplate code:
_ = s.map {print($0)}

···

On 23.06.2016 19:26, Dmitri Gribenko via swift-evolution wrote:

On Thu, Jun 23, 2016 at 9:25 AM, James Campbell via swift-evolution > <swift-evolution@swift.org> wrote:

Dmitri