So if the function I run inside of the map has a return value of Void will that still compile ?
*___________________________________* *James⎥Head of Trolls* *ja...@supmenow.com <ja...@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_r...@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* > > *ja...@supmenow.com <ja...@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 <s...@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 >> > >> > ja...@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