[swift-evolution] [Review] SE-0006 Apply API Guidelines to the Standard Library
dabrahams at apple.com
Thu Jan 28 00:42:57 CST 2016
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”
>> But that's not how they're used. I'd have to rename Equatable and
>> Comparable to follow that convention.
>> swift-evolution mailing list
>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution