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?
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.
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.
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 ā
-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.
Rideable and slideable are in the OED.
Next April, we should suggest typealias šable = Codable.
Swift evolution proposal, or it didn't happen ;-)
?