[swift-evolution] Shorthand unwrap proposal

[Jordan Rose]

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 at 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 at supmenow.com <mailto:james at 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 at fifthace.com <mailto:sean at 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 at swift.org <mailto:swift-evolution at 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 at supmenow.com <mailto:james at supmenow.com>⎥supmenow.com <http://supmenow.com/>
> >
> > Sup
> >
> > Runway East
> >
> >
> > 10 Finsbury Square
> >
> > London
> >
> > > EC2A 1AF
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <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/20160623/224a22a1/attachment.html>