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 > <[email protected]> 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 > > [email protected] <mailto:[email protected]>⎥supmenow.com > <http://supmenow.com/> > Sup > > Runway East > > > 10 Finsbury Square > > London > > > EC2A 1AF > > > On 23 June 2016 at 17:11, Sean Heber <[email protected] > <mailto:[email protected]>> 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 > > <[email protected] <mailto:[email protected]>> 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 > > > > [email protected] <mailto:[email protected]>⎥supmenow.com > > <http://supmenow.com/> > > > > Sup > > > > Runway East > > > > > > 10 Finsbury Square > > > > London > > > > > EC2A 1AF > > > > _______________________________________________ > > swift-evolution mailing list > > [email protected] <mailto:[email protected]> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
