[swift-evolution] [Review] SE-0023 API Design Guidelines

[Dave Abrahams]

on Sat Jan 23 2016, Joe Groff <swift-evolution at swift.org> wrote:

>> On Jan 23, 2016, at 1:23 PM, Dave Abrahams via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>> 
>> on Sat Jan 23 2016, Thorsten Seitz
>
>> <swift-evolution at swift.org
>> <mailto:swift-evolution at swift.org>>
>> wrote:
>> 
>>> I never liked the convention of distinguishing between interfaces and
>>> classes by prepending an „I“ for interfaces in other languages and I’m
>>> not overly fond fond of the suffix „Type“ currently used in Swift
>>> protocols.
>>> This is the same as prefixing (or suffixing) variable names with
>>> something to express their type, e.g. `String sName` or `int iLength`.
>>> That’s what we have type information for. 
>>> 
>>> And because of the substitution principle it should make no difference
>>> whether I have a protocol or a struct or class. What is a
>>> `CollectionType` vs. a `Collection`? Is it the type of a `Collection`,
>>> i.e. a meta type? 
>> 
>> Yes, that was the original rationale, FWIW.
>> 
>>> Why not simply `Collection` if it describes what a collection is?  I
>>> guess its often more the problem of finding a suitable different name
>>> for the implementation 
>> 
>> Yeah, often we'd have a collision with an associated type.
>> 
>>> and that’s why I sometimes wonder whether it
>>> might make sense to give protocols their own namespace…
>> 
>> Can't do that as long as we have protocols that can function as concrete
>> types (existentials).
>
> You've noted before that this is a recipe for confusion, especially
> if/when we ever extend existentials to cover protocols with Self
> and/or associated type constraints. It's probably a better long-term
> direction for the protocol type to be something you ask for (as
> "any<Protocol>", maybe), and for protocols to live in a separate
> namespace.

Nice idea, but I'm not it will work:

    protocol P { }
    class P { }
    struct X<T: P> { } // which P?

anyhow, I guess more discussion of that idea should be in a separate
thread.

-- 
-Dave