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

[Goffredo Marocchi]

I never liked the practice of having classes and protocols with the same name, like NSObject, although legal and maybe very reasonable at times. A protocol should express what it is, a contract.

Sent from my iPhone

> On 30 Jan 2016, at 09:48, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I still don’t see why we need a suffix at all, what is unclear about the CollectionType protocol simply being called Collection instead? It’s declared as a protocol after all, so there’s no risk of someone accidentally instantiating one.
> 
>> On 30 Jan 2016, at 02:47, Alex Migicovsky via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> IMO the ‘like’ suffix makes it sound like the conforming type to Collectionlike is like a Collection, but not exactly a Collection. Maybe there’s another suffix that works but I don’t think this one conveys the right information.
>> 
>> - Alex
>> 
>>>> On Jan 29, 2016, at 6:43 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> Count me among those who liked the ‘Type’ suffix for protocols though.
>>> 
>>> I wonder if we can't change it to a -`like` suffix. Applying that to 2.1 stdlib gives you:
>>> 
>>> AnyCollectionlike
>>> BidirectionalIndexlike
>>> BitwiseOperationslike
>>> Booleanlike
>>> CVarArglike
>>> Collectionlike
>>> Errorlike
>>> FloatingPointlike
>>> ForwardIndexlike
>>> Generatorlike
>>> IntegerArithmeticlike
>>> Integerlike
>>> Intervallike
>>> LazyCollectionlike
>>> LazySequencelike
>>> MirrorPathlike
>>> MutableCollectionlike
>>> OptionSetlike
>>> OutputStreamlike
>>> RandomAccessIndexlike
>>> RangeReplaceableCollectionlike
>>> ReverseIndexlike
>>> Sequencelike
>>> SetAlgebralike
>>> SignedIntegerlike
>>> SignedNumberlike
>>> UnicodeCodeclike
>>> UnsignedIntegerlike
>>> 
>>> Not all of these are perfect, but in some cases that's because they should arguably be -able protocols (BitwiseOperationsType -> BitwiseOperable).
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160130/8085201a/attachment.html>