Typealias Stridable = Strideable

All other "-able"-suffixed protocols whose verb forms end with "e" have their final "e" dropped according to english grammar, e.g. Codable, Equatable, and Comparable. It's rather inconsistent to have Strideable instead of Stridable.

Does the Swift community here think that adding typealias Stridable = Strideable to the standard library is warranted? And given how superficial this change is, does it require a evolution proposal?

2 Likes

It most definitely would need an evolution proposal. Given how firmly established it is that we aren’t renaming things that even have a reasonable justification (like filter), I’d see there as zero chance of this being changed for something as trivial as a debatable spelling.

Regarding the rules of grammar: Swift is venturing into territory that isn’t really covered by your link, because it sticks “-able” in so many places not covered by dictionaries or common usage. And as always in English, there are exceptions and the rules aren’t so definitive as you make out. Both Websters and the OED list “Saleable” is a valid spelling, for example.

Personally, I much prefer strideable or inlineable because without the e, they look like striddable or inlinnable (and codable looks very fishy). The same reasoning as your link gives for including the e after ce or ge, essentially.

Unfortunately, we’ve failed to be consistent in this regard over the years so we have strideable but not inlineable. But, like I say, the idea we’d change names purely to make them consistent (even with a low-impact type alias) is out of the question IMO.

1 Like

Perhaps adding to your point, among "-able"-suffixed words is "strikeable". It's a very interesting case because "stride" and "strike" differ by only 1 letter. And because "strikeable" retains the "e", even though "k" doesn't need it to disambiguate for a soft sound (silibant?) like "c" and "g" do.

Sorry if this is a bit of a tangent, but this reminds me of how the Haskell compiler GHC supports both American and British spellings in places, like the language extension GeneralisedNewtypeDeriving/GeneralizedNewtypeDeriving.

GeneralisedNewtypeDeriving
GeneralizedNewtypeDeriving
Since:	6.8.1. British spelling since 8.6.1.

There was even a bug report for it! GHC 8.2 does not accept British {-# LANGUAGE GeneralisedNewtypeDeriving #-} spelling.

4 Likes

The spelling was an intentional choice.

<rant>
They didn't consult me for Codable, which is why we didn't end up with Serializable, which every coder(!) in the world would have recognized for what it is. Instead we got the invented concept “coding” that is neither related to every programmer's primary activity, nor encryption, and a name that elicits the pronunciation “:fish:-able.”
</rant>

By the same token, the normal rules of English pronunciation—such as they are—suggest that Stridable could be pronounced “strid-able.” Since most dictionaries admit both forms of words like “tuneable”/“tunable” and we did have to invent a new concept, we wanted the name to guide people to the right interpretation.

1 Like

Rideable and slideable are in the OED.

Next April, we should suggest typealias 🐟able = Codable.

7 Likes

Why wait :wink:?
/cc @Chris_Lattner3

Swift evolution proposal, or it didn't happen ;-)

I did my part

1 Like