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

[davesweeris at mac.com]

Huh… Yeah, you’re right. I guess I saw “CollectionType” and “CustomStringConvertible” or something and made a connection that wasn’t there.
Well, FWIW, that convention (plus the occasional “HasNoun”, and -ableType for constraining the element of custom collections) tends to work well for me.

What’s been the deciding factor between -Type and -able so far?

- Dave Sweeris

> On Jan 27, 2016, at 00:49, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 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.
> 
> -- 
> -Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution