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

[Dave Abrahams]

on Sat Jan 30 2016, Haravikk <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.

+1

One thing we love to do, as programmers, is set up systems of
organization that classify and categorize things.  It's almost reflexive
and instinctual for many of us, and we seldom ask ourselves whether the
system of organization is pulling its weight, which is IMO why we got
code like what's shown in http://stackoverflow.com/q/321413.

The one thing that originally pushed me toward the “Type” suffix for
protocols was the fact that we were starting to see associated types
whose names were the same as the protocols they modeled, e.g.

  associatedtype Generator : Generator

But this has in fact proven to be a rare occurrence, and just like there
are usually better names for variables than the names of their types,
there are usually better names for associated types than the names of
their protocols, e.g. 

  associatedtype IterationState : Generator

>> 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
>>> <mailto: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
>>> <mailto: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

-- 
-Dave