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

[Dave Abrahams]

on Wed Jan 27 2016, Dave <swift-evolution at swift.org> wrote:

> 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?

When there's no reasonable -able or -ible name, use -Type.

> - 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave