[swift-evolution] Shorthand unwrap proposal

L. Mihalkovic laurent.mihalkovic at gmail.com
Thu Jun 23 13:27:32 CDT 2016


and before someone points it out, yes the follow does work, but i just thought the long form was easier to understand



extension Optional {
    func unwrap<T> (_ h: T -> ()) {
            if let t = self as? T { h(t) }
    }
}
Regards
(From mobile)

> On Jun 23, 2016, at 8:19 PM, L. Mihalkovic <laurent.mihalkovic at gmail.com> wrote:
> 
> 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 at 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 at supmenow.com⎥supmenow.com
>> 
>> Sup
>> 
>> Runway East
>> 
>> 
>> 10 Finsbury Square
>> 
>> London
>> 
>> 
>> EC2A 1AF 
>> 
>> 
>>> On 23 June 2016 at 17:22, Jordan Rose <jordan_rose at 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 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⎥supmenow.com
>>>> 
>>>> Sup
>>>> 
>>>> Runway East
>>>> 
>>>> 
>>>> 10 Finsbury Square
>>>> 
>>>> London
>>>> 
>>>> 
>>>> EC2A 1AF 
>>>> 
>>>> 
>>>>> On 23 June 2016 at 17:11, Sean Heber <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> 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⎥supmenow.com
>>>>> >
>>>>> > Sup
>>>>> >
>>>>> > Runway East
>>>>> >
>>>>> >
>>>>> > 10 Finsbury Square
>>>>> >
>>>>> > London
>>>>> >
>>>>> > > EC2A 1AF
>>>>> >
>>>>> > _______________________________________________
>>>>> > 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/20160623/2603a6a1/attachment.html>


More information about the swift-evolution mailing list