If you are confused by what $0 represents then your shouldn't use the short hand version of writing a block. The long version includes the type which will remove all mysteries
// What is $0 array.map { $0.method() } // No mystery of $0. It is clearly a String? array.map { (name: String?) -> String? return name?.uppercased() } On Tue, Dec 6, 2016 at 10:16 PM Jay Zhao <zhaojian...@icloud.com> wrote: > Hi Derrick, > > Not just for optional array, but for all optional types. Optional.map has > a deep confusion for we’re not sure what is $0 inside. And it is so > commonly used compared to the collection of collection scenario mentioned > by Alexis Beingessner. > > - Jay Zhao > > On 7 Dec 2016, at 10:58, Derrick Ho <wh1pch...@gmail.com> wrote: > > Jay, I fail to see the point you are trying to make. Can you clarify why > we need a new map method for an optional array of elements? > > On Tue, Dec 6, 2016 at 9:46 PM Jay Zhao via swift-evolution < > swift-evolution@swift.org> wrote: > > It applies in theory to think Optional as a collect of one and for that > reason map is a perfect name. > > But in practice, we often use the same variable name for *array* and > *array?* . So when you see : > cars.*map*({...$0...}) > You can not tell which map and even worse which $0 it is. > > According to Swift API Design Guidelines *#1*, *Clarity at the point of > use*. > And to combine theory and practice, I propose *mapUnwrapped* to remove > the confusion. > > Actually this is what’s been adopted in my company: > > public extension Optional { > > /// Pass the `Optional` into the closure that returns `Non-Optional` > > public func mapUnwrapped<U>(_ transform: (Wrapped) throws -> U) > rethrows -> U? { > > return try map(transform) > > } > > } > > To summary my idea: > This is the situation where usability > design purity for a language(a > tool). > > > > On 7 Dec 2016, at 08:05, Robert Widmann <devteam.cod...@gmail.com> wrote: > > If you think of Optional as a zero-or-one element collection there's > really no reason this operation should be named any differently. It still > lifts a function over values to one over Optionals. It still extracts the > contents of the structure and applies the function (propagating failure if > necessary). The operation is no different from the one required of a plain > Sequence conformance, why should it have a new name if it is not a new > operation? > > ~Robert Widmann > > 2016/12/05 22:46、Jay Zhao via swift-evolution <swift-evolution@swift.org> > のメッセージ: > > Hi there, > > Code explains everything: > > > /// Maybe a bad API naming in Swift? See below: > > /// array1 can be array of any object that have a `count` method > let array1 = [[String]]() > let array2 :[String]? = nil > > > // I believe the confusion between `array.map` and > `optionalArray.map` is really bad. > // Because when you read code like this, you can not tell which > is which: > _ = array1.map({$0.count}) > _ = array2.map({$0.count}) > > // It can be clearer: > // 1, we pass `self.element` into the closure > _ = array1.map({$0.count}) > // 2, we pass self directly into the closure > _ = array2.mapMe({$0.count}) > > > The mapFlat method is also problematic. > > Yours, > Jay Zhao > > _______________________________________________ > 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