> On 16 Jun 2016, at 08:39, Brent Royal-Gordon via swift-evolution > <[email protected]> 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 ;) _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
