> On Dec 31, 2015, at 8:44 AM, Susan Cheng <[email protected]> wrote: > > What's problem of overloading? We only have four methods to do so.
The set of potential algorithms using comparison predicates is not closed, and they will be implemented not only by the standard library but also by third parties. One component gets us the functionality for all those algorithms. > > Dave Abrahams <[email protected] <mailto:[email protected]>> 於 > 2016年1月1日星期五 寫道： > >> On Dec 31, 2015, at 4:14 AM, Tino Heth <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >> >>> func byComparing<T, U: Comparable>(getComparisonKey: (T)->U) -> (T, T) -> >>> Bool { >>> return { getComparisonKey($0) < getComparisonKey($1) } >>> } >> I've written something similar to bring file URLs into the order of their >> creation dates. >> It is a small extension for collection types, and its only downside will >> disappear as soon as properties are accessible via method calls (afair there >> is a proposal in the making). >> >> It was quite a lot fiddling with generics, and I don't have the tiny piece >> of code on my own computer, but it works in a way that you can do >> let sorted = array.sortUsingAccessor(ElementType.methodThatReturnsComparable) >> Beside the problems with properties, I really liked that approach. > > This seems to be essentially the same design as Susan’s, and has the same > problem: it requires a new overload for every algorithm that takes a > comparison predicate. > > -Dave > -Dave
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
