on Tue Apr 19 2016, "Vladimir.S" <svabox-AT-gmail.com> wrote:
> Agree with notes about minIndex vs indexOfMin. Seems clear for me the > later should be chosen. We have .min() so it is naturally to have > .indexOfMin > > But I disagree on specialized algorithms. Can't understand, how > custom-made function with block with comparision is better than > handful, clear and explicit method. It's important, as a baseline, for the library to provide all the right primitives that you can combine to easily get most jobs done. After that, the bar for expanding the API surface area gets much higher, because greater API surface area means more complexity for users to confront. The usual criterion is, “is it hard to write (correctly and performantly) yourself?” I think this one fails that test. > Btw, I feel your "composition" is not obvious on what is going on from > first look and if instance name is somethingDescriptive you'll have > very long expression instead of method with clear name and obvious > meaning. > > What is wrong to have a set of useful and explicit methods for basic > operations on array, map, set etc? Nothing at all, but there's a balance to be maintained between design coherence, graspability of the whole API, convenience, and many other factors. > > > On 19.04.2016 21:12, Dave Abrahams via swift-evolution wrote: >> Just with regard to naming, I don't think these work. I read “minIndex” >> as “the minimum index,” and since we expect all indices to be >> comparable, that clearly implies c.minIndex() == c.startIndex. I think >> you'd need “c.indexOfMin()” >> >> I am also really reluctant to add specialized algorithms for things >> that can be trivially composed out of existing parts, e.g. >> >> c.indices.min { c[$0] < c[$1] } >> >> Once we start down this road, we very quickly end up with mapValues, >> mapKeys, indexOfMinimumKey, etc. -- Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution