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

[Brent Royal-Gordon]

> Maybe this has been addressed before on another topic, but why are minmax(), minIndex(), maxIndex() and minmaxIndices() functions rather than read-only properties?

The API Guidelines say this:

>>> Document the complexity of any computed property that is not O(1). People often assume that property access involves no significant computation, because they have stored properties as a mental model. Be sure to alert them when that assumption may be violated.

It's not stated outright, but that also sort of implies that you should generally prefer to make a non-O(1) operation a method, not a property. There are lots of borderline cases—`count` is O(n) for the general case of a Sequence or Collection, but it's O(1) for many of the most common types like Array, so it's made a property even though that might be confusing. Very few types would have O(1) `min/maxIndex`, so it doesn't seem appropriate to use methods.

Also, non-`Comparable` collections would need a form which takes a comparison function as a parameter. That means method.

> Also, I’d favour “bounds”, “boundaries” or “limits” over minmax. There are plenty of English words which better and more precisely describe what it provides.

These all sound like words for the `start/endIndex`. That's a problem with this proposal more generally; I'm not really in favor.

(I wonder if instead, there should be an operation like reduce(_:combine:) but with a function parameter which returns a Bool, and which ends up returning the last element which the function returned true for.)

-- 
Brent Royal-Gordon
Architechies