[swift-evolution] API Guidelines: dropFirst?

[Haravikk]

> On 16 Jun 2016, at 08:39, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> 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.

I’m not a big fan of the term of art exception personally.

That said I actually think it’s useful to have these methods slightly different as if I understand them correctly they’re not strictly non-mutating; a Sequence doesn’t guarantee that it can be consumed over and over without changing, as it could represent a buffer or some other construct that’s consumed as it’s accessed, so calling dropFirst() on a sequence, then calling it again on the same sequence may not yield the same result both times, for that you want a Collection (or a specific sequence implementation with well defined behaviour), but for a generic sequence I don’t think you can trust the method to be non-mutating unless you know what the sequence is backed by, so it shouldn’t follow the rule for non-mutating methods.

Of course this gets us into a weird position when it comes to naming things consistently, because it means the name follows the mutating naming convention because it *could* be mutating behind the scenes. It’s one of those areas where things get confusing, as because a type is a struct, doesn’t mean it doesn’t use a share class instance behind the scenes for example, fun stuff ;)