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

[Haravikk]

> On 30 Jan 2016, at 09:53, Brent Royal-Gordon <brent at architechies.com> 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?
> 
> They're attractive nuisances. Someone wants an integer type, sees Integer, tries to use it, and suddenly they're getting weird errors about Self and associated object requirements. Or they want a boolean variable, see Boolean, and suddenly their one-bit value is wrapped in a 40-byte protocol witness. Nobody is going to mistake Integerlike or Booleanlike for a concrete type and use it accidentally.

The first example (errors about Self) is more a problem with the error being confusing to new users, first time I encountered that was a real head-scratcher as I was trying to use a protocol as a type for a variable (which is still a problem with Swift really, since some can be used and others can’t). Anyway, the fact is that it returns an error; while the error may currently be hostile to new users, that’s its own problem IMO.

I’m also not sure what you mean about the overhead on BooleanType being misused as Boolean? It can’t be instantiated directly, and with that specific example I’ve never seen code that doesn’t use true/false directly anyway (or some comparison like someInt != 0). Bool doesn’t really have initialisers that need to be used much.

I suppose if we do have to have a suffix though then I would also prefer Like over Type; Type to me isn’t a good fit as not every protocol can be used as a type (due to aforementioned Self restrictions), whereas describing it as like something is essentially what a protocol does, as a struct could theoretically be IntegerLike without being backed by an integer at all.