Bad naming in Standard Library

[Jens]

I just made the exact same mistake (again) as described in this 4 year old thread:

rename dropFirst() and dropLast()

Hi all, Today I made a mistake trying to use .dropFirst() to remove an array element in-place. I have the feeling that I will second-guess myself the next time. IHMO, now that dorpFirst() is no-longer a free function, it's name is hardly distinguishable from .removeFirst(). When compared side-by-side, .dropFirst() does seem to suggest “return the rest". But this subtlety is easily lost for users who don’t use both on regular bases. It’s worse for non-native English speakers. Looking at a few…

Why hasn't dropFirst() and dropLast() been renamed (to eg droppingFirst() and droppingLast())?

I mean, according to the API naming guidelines and the resulting "feel" of the language, .dropLast() would be a mutating method that removes the last element, ie something very similar to the existing methods .removeLast() and popLast().

---

Are there other similarly bad names in the Standard Library?

[masters3d (Chéyo Jiménez)]

All the term of art like map, filter, etc.

[Chris_Lattner3 (Chris Lattner)]

@Jens

Why hasn't dropFirst() and dropLast() been renamed (to eg droppingFirst() and droppingLast() )?

I'm very +1 on fixing that, I assume that it is just the case that no one has proposed it. It should be straight forward to introduce the proper names and deprecate the old ones.

-Chris

[Jens]

@Chris_Lattner3

It should be straight forward to introduce the proper names and deprecate the old ones.

I don't have the time to write formal proposals, and I'm not sure what the proper names would be, some examples I can think of right now:

withoutFirst()
droppingFirst()
skippingFirst()
removingFirst()

(And the same for …Last())

[beccadax (Becca Royal-Gordon)]

@Chris_Lattner3

I'm very +1 on fixing that, I assume that it is just the case that no one has proposed it.

I proposed it at the end of the Swift 3 cycle, but it got returned for revision, there wasn’t enough time to run it again, and then we declared source compatibility. The proposal is still in the repo—I think it was somewhere around 130, but I could be wrong. If we’re okay with the source compatibility impact, we could dust it off and modify it to deprecate the old names without removing them.

Edit: Now that I'm not on my phone, I've looked it up: SE-0132 Rationalizing Sequence end-operation names

[Jared_Khan]

Hi @beccadax, just browsing and came back to this post since it's the most recent mention of that proposal I could see.

I'd really like to see this happen. Your proposal is the most thorough and thought-out proposal I've seen to address the naming issues. The most recent rejection from the core team that I could see was that the renamings are "too extensive to consider given Swift's source compatibility goals". This makes sense but seems an unfortunate reason to discard this proposal.

Did you consider revisiting the proposal to reduce the scope? Do you think that's something the core team would be open to? Are you aware of other proposals covering any of these changes?

[tonyarnold]

I would really like to see SE-0132 picked up in it's entirety, too - the API naming here has always seemed inconsistent.

It sounds like the rejection was more about timing than anything else?

[mattrips]

These function names are simply wrong given Swift’s naming conventions. Causes me to waste time and brainpower on a regular basis.

@beccadax, if you have time to dust off the proposal and change it to use depreciations rather than replacements, I’d gladly load up your favorite coffee shop card.

[waterform]

I read it, used it multiple times, but if someone would wake me up in the middle of the night I would do it wrong. This is a quirk which should be fixed. Because it is easy for me to say to newcomers "just learn it, even if it doesn't make sense", but teaching quirks is always dumb for the students. I know API-Design is hard, but changes should be possible with a longer deprecation period for the old way.