On 24.06.2016 0:55, Anton Zhilin via swift-evolution wrote:
Dave Abrahams via swift-evolution <swift-evolution@...> writes:A couple of weeks ago we started to notice that we had some poorly-namedclosure parameters and argument labels in the standard library, so we did a complete audit of the standard library's APIs and came up with a preliminary proposal for changes, which we applied in a branch and you can review in https://github.com/apple/swift/pull/2981. Let's please carry on further discussion here rather than in the pull request,though. I don't like that more clutter is added to the call site. We can surely find shorter and more descriptive names. Remember that most people already know what filter, map and reduce means, we don't need to explain them. My suggestions: filter(where:) map(over:) reduce(applying:) sort(by:)
Do you mean *sorted*(by:) ? Or I'm missing something in naming rules?
forEach(do:) Remember that these functions came from functional languages, where function names tend to be brief, and it is considered one of their advantages.
+1
Data flow is an area where code becomes the less understandable when more visual clutter is added. In my opinion, array.filter(isEven).map(square).reduce(sum) reads better than array.filter(suchThatTrue: isEven).map(applyingTransformation: square).reduce(accumulatingResultBy: sum) What do you think?
+100. I even want to brought the term-of-art argument here. IMO These functions are expected to be called without any parameter names.
From other point, often these functions will be called with closures(i.e. without parameter names at all):
array.filter {$0 % 2 == 0} .map {$0*$0} .reduce(0) {$0+$1}
_______________________________________________ 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
