[swift-evolution] [Draft] Expanded min/max algorithms
brent at architechies.com
Wed Apr 20 03:14:43 CDT 2016
> 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.)
More information about the swift-evolution