[swift-evolution] API Guidelines: dropFirst?

[Vladimir.S]

On 16.06.2016 10:39, Brent Royal-Gordon via swift-evolution wrote:
>> What is the rationale behind the name dropFirst()? Being a
>> non-mutating method it should clearly be e.g. droppingFirst()
>> according to the API Naming Guidelines.
>
> Like many `Sequence` and `Collection` operations, `dropFirst()` is a
> result of the "term of art" exception, which is implied by the "Use
> Terminology Well" section of the API Guidelines:
> <https://swift.org/documentation/api-design-guidelines/#use-terminology-well>
>
>  Many languages use `dropWhatever` or `drop_whatever` for operations
> which return some sort of list with some of its leading or trailing
> elements removed. For instance:
>
> * Ruby (which I happen to have in Dash) has `drop(n)` and `drop_while`
> methods. * Haskell has `drop n`, `dropWhile`, and `dropWhileEnd`
> functions. * Scala has a `drop(n)` method. * R has a `dropFirst`
> function.
>
> The standard library has chosen to break its usual patterns in order to
> maintain consistency with languages like these.
>
> Personally, I believe the term of art exception has been misapplied in
> this area of the language; the precedents are not very strong, and the
> resulting APIs form a patchwork of inconsistent names rather than a
> coherent family. The term of art exception increases the clarity of
> calls like `map` and `filter` where the names are truly universal, but
> it impedes the clarity of the whole family of
> `first`/`prefix`/`suffix`/`last` calls, and the names should be
> revisited and rationalized. But that hasn't happened yet.
>

Agree with your opinion. As I understand, these languages are functional 
languages or languages that have non-mutating methods as 1st class 
citizens. That is why 'dropX' in them by default means non-mutating method. 
They just don't need to somehow highlight that the method is non-mutating 
(but can highlight mutatuing method as in Ruby with '!').

In Swift prior 3.0 we had the same situation : there was 'default' 
non-mutating method and 'xxInPlace' for mutating method. Now, in Swift 3 we 
have "default" name for mutating methods and changed(to highlight) names 
for non-mutating. I believe there is no sense to leave methods other than 
(map/filter/reduce) in their initial view as this IMO will only confuse 
Swift coders that will expect 'droppingXXX' for non-mutating method.

IMO To keep the consistency with modern languages, we should have 
non-mutating methods with "default" name and "modified" for mutating.
As this solution was not chosen, then IMO we need to keep just 
map/filer/reduce for non-mutating as "term of art" and explicitly highlight 
that in documentation but use accepted naming rules for *all* other method 
names to reduce the confusion. Only in this way we'll have consistency and 
clear rules for naming. Otherwise we'll have a situation with naming in 
Swift 3.0 worse than in Swift 2.

And, if I don't need know/use these languages, why should I care of their 
naming elsewhere and have non-consistent names for some Swift methods?!

Btw, can't we say that 'sort' is also a term of art?