[swift-evolution] [Draft] Expanded min/max algorithms

[Dave Abrahams]

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