[swift-evolution] API Guidelines: dropFirst?

Dave Abrahams dabrahams at apple.com
Thu Jun 16 09:43:57 CDT 2016


on Thu Jun 16 2016, Brent Royal-Gordon <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 agree that we need to revisit this area. Even filter can potentially
be improved upon.  The polarity of its closure is far from obvious even
if you know the terms of art.

-- 
-Dave



More information about the swift-evolution mailing list