I like it, but it's unfortunately missing in the shorter overload. Another idea would be to put sorted in the base name:
sortedMin(count:), sortedMin(count:by:)sortedMax(count:), sortedMax(count:by:)OTOH, if we find no way to communicate in the function name that max(count:) returns the result in ascending order, I agree with @hisekaldma that max(count:) seems like it should return elements in decreasing order.
What do we think of using the actual algorithm name for this -- partialSort? It seems hard to fit this in an "obvious" name because the behavior is already quite specific. Sorta like how merge sorting would likely be called mergeSort instead of something descriptive like sortedThoughConsecutiveDivision.
Using "partial sort" in the name is a valid direction, but the notable difference to also take into account is these (non-in-place) functions only return the sorted part at either end of the partially sorted list. So we should also communicate that in some way, such as min/max or prefix/suffix.
I don't think this is true for two reasons.
First, there's no precedent in the standard library today for first(5) or last(5), so there should be no confusion with existing API. sortedPrefix could be confusing because users mistake it for prefix(5).sorted() instead of sorted().prefix(5). I don't think that confusion would last long, but it exists.
Second, firstSorted and lastSorted do not have the same sort of grammatical ambiguity that sortedPrefix does. Since prefix can be both a noun and a verb, there's a natural ambiguity in its use. As a noun, prefix uses sorted as an adjective, making a new noun, sortedPrefix. As a verb, however, prefix uses sorted as an adverb, creating the phrase sorted prefix. This usage isn't really grammatical, but it sounds natural, and so may confuse the user about whether the method does something or is something.
Now, technically, first and last can also serve as adverbs, but they're primarily ordinal values, so there should be little inclination for people to mistake the forms. Additionally, firstSorted and lastSorted rely on the first parameter (e.g. firstSorted(5)) to become a grammatical phrase, and so should help users understand that it's all one action producing one result, rather than some combination of things.
The existing connotations in the stdlib of the terms "first" and "last" are about position in the sequence, while "min" and "max" are about the values of the elements.
I see what you're saying about how thinking of the "minimum" User can be counter-intuitive, however I think it's important to be consistent about the connotations of the terms we use, and I think using the terms "first" and "last" here, would dilute them.
This is exactly my point. If we can't use prefix/suffix, then first/last give us an indication we're talking about relative position. firstSorted combines that notion with the fact that the collection is being sorted to give the user more information. min and max dealing with values of elements is exactly why I don't think they're appropriate here. We're applying a predicate to get a particular order, not just picking particular values.
Even if we did dilute the meaning (which I don't think it really does), does that dilution even matter? We would just be expanding first from "first element" to "first elements". I agree that it's not ideal, but then the correct name has been ruled out, so every name will have compromises somewhere. Personally, I like these compromises better than using min / max since it still conveys as much useful information as possible as well as only diluting an already similar term instead of one further from the intended meaning.
But no: it’s precisely that we are picking particular values, no more or less here than the existing min and max, and without reference to the position of these elements relative to each other in the current collection. In fact, you cannot pass a predicate for a custom sort based on the indices or offsets.
First elements of what? There is no collection that the user can observe for which these elements are first.