[swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library

Dave Abrahams dabrahams at apple.com
Wed Jan 27 02:49:41 CST 2016

on Tue Jan 26 2016, Dave <swift-evolution at swift.org> wrote:

>> On Jan 25, 2016, at 07:40, Radosław Pietruszewski via
>> swift-evolution <swift-evolution at swift.org> wrote:
>> == Removed Type from protocol names ==
>> Perhaps I’ve missed some discussion about this and I don’t see the
>> context, but I’m not sure this is a positive change.
>> I fear this might be confusing in practice, at least in some
>> contexts. For example, there's nothing signifying that "Boolean" or
>> "Integer" are protocols and not actual types. Same with “Sequence”,
>> “OptionSet”, etc. Perhaps it doesn't matter because everyone will
>> naturally go for `Bool`, `Int`, and `Array` anyway. But I can
>> imagine a lot of confusion if someone tried that anyway, or perhaps
>> saw that in the autocompletion, or the standard library browser
>> (with no intention of using the protocol).
>> I’m all for removing unnecessary noise and verbosity, but I think I
>> would err on explicitness side here. It seemed like the -able/-Type
>> convention did a good job disambiguating types you can actually
>> instantiate from protocols, with very little “verbosity cost”.
> Same here… I like -Type for protocols that can only be used a generic
> constraint, and -able/-ible for protocols that can be “concrete”
> types.

But that's not how they're used.  I'd have to rename Equatable and
Comparable to follow that convention.


More information about the swift-evolution mailing list