[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