[swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

[Goffredo Marocchi]

Sent from my iPhone

> On 22 Jul 2016, at 19:10, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
>> On Fri, Jul 22, 2016 at 1:04 PM, Goffredo Marocchi <panajev at gmail.com> wrote:
>> This adds information without being a burden while the current approach mixes and matches in a workable but less consistent way.
> 
> It adds no *useful* information.
> 
>> Adopting a protocol is not the same as subclass for, why should it look the same syntax wise?
> 
> As Daniel has pointed out, `class A : P { ... }` establishes a relationship such that `A is P`, regardless of whether P is a protocol or base class.

I do not think it is a fair statement IMHO. A can conform to P and/or be an A. I think the two concepts should stay separate as they are in many languages, but I can accept to be on the losing end of this.

> 
>> Sent from my iPhone
>> 
>>> On 22 Jul 2016, at 19:00, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>> 
>>>> On Fri, Jul 22, 2016 at 12:42 PM, Leonardo Pessoa via swift-evolution <swift-evolution at swift.org> wrote:
>>>> It would still cause confusion if you were only to conform to a single
>>>> protocol (P in "class A : P" is a class or a protocol?). This can be
>>>> solved in code but I don't think it is necessary.
>>> 
>>> The point made earlier is salient: if you know what P is, no clarification is necessary; on the other hand, if you don't know anything else about P, knowing whether P is a class or protocol is essentially useless even if you're a reader. What could you possibly do with this information?
>>> 
>>>> L
>>>> 
>>>> 
>>>> On 22 July 2016 at 14:08, Goffredo Marocchi via swift-evolution
>>>> <swift-evolution at swift.org> wrote:
>>>> > I think that the current approach marks a regression in declarative
>>>> > expressiveness as the notion of extending a class over implementing a
>>>> > protocol is blurred while the concepts are IMHO not the same (the latter is
>>>> > about behaviour conformance not a is a relationship):
>>>> >
>>>> > Class/struct B : Class/struct A <Protocol1 & Protocol2>
>>>> >
>>>> >
>>>> > would be a clear and concise way to express it that would not be confused
>>>> > even at a quick glance.
>>>> >
>>>> > Sent from my iPhone
>>>> >
>>>> > On 22 Jul 2016, at 14:47, Charlie Monroe via swift-evolution
>>>> > <swift-evolution at swift.org> wrote:
>>>> >
>>>> > I agree that this is an issue. Mostly nowadays when more and more classes in
>>>> > Swift do not have a superclass - it simply looks weird:
>>>> >
>>>> > class MyClass: DataSource
>>>> >
>>>> > One doesn't know whether "DataSource" is a class, protocol, etc.
>>>> > Nevertheless, I do not feel that :: is the answer. I really liked, how ObjC
>>>> > did it (which isn't possible with the generics now - is it?), but what about
>>>> > something like this?
>>>> >
>>>> > class BaseClass [SomeDelegate, OtherDelegate, ProtocolX]
>>>> > class MyClass: BaseClass [SomeDelegate, OtherDelegate, ProtocolX]
>>>> > extension MyClass [OtherProtocol]
>>>> >
>>>> >
>>>> > On Jul 22, 2016, at 3:14 PM, Vladimir.S via swift-evolution
>>>> > <swift-evolution at swift.org> wrote:
>>>> >
>>>> >
>>>> > I remember that this was discussed, but can't find any decision regarding
>>>> > this.. So, as a last chance, don't we want in Swift 3.0, as big source
>>>> > breaking change, separate class inheritance and protocol conformance in
>>>> > syntax?
>>>> >
>>>> >
>>>> > Sorry if there was a decision about this suggestions. Please let know in
>>>> > this case.
>>>> >
>>>> >
>>>> > I.e. when I see the following I can't understand if the class inherits from
>>>> > base class and conforms to protocols or just conforms to two protocols:
>>>> >
>>>> >
>>>> > class MyClass : First, Second, Third {
>>>> >
>>>> > }
>>>> >
>>>> >
>>>> > We don't have a rule to name protocols with 'Protocol'/other suffix/prefix,
>>>> > or classes with 'T'/'C' prefix or something like this, so I believe to
>>>> > improve the clarity of code we should separate in syntax inheritance and
>>>> > conformance.
>>>> >
>>>> >
>>>> > As I understand we should discuss changes in these areas:
>>>> >
>>>> >
>>>> > 1. class inheritance :
>>>> >
>>>> > class Child: BaseClass
>>>> >
>>>> >
>>>> > 2. class conformance :
>>>> >
>>>> > class Child: SomeProtocol1, SomeProtocol2
>>>> >
>>>> >
>>>> > 3. class inheritance + conformance :
>>>> >
>>>> > class Child: BaseClass, SomeProtocol1, SomeProtocol2
>>>> >
>>>> >
>>>> > 4. protocol conformance for structs:
>>>> >
>>>> > struct Struct: SomeProtocol1, SomeProtocol2
>>>> >
>>>> >
>>>> > 5. protocol inheritance:
>>>> >
>>>> > protocol Child: BaseProtocol1, BaseProtocol2
>>>> >
>>>> >
>>>> >
>>>> > My suggestions:
>>>> >
>>>> >
>>>> > I) separate inheritance with double colon :
>>>> >
>>>> >
>>>> > 1. class inheritance :
>>>> >
>>>> > class Child:: BaseClass
>>>> >
>>>> >
>>>> > 2. class conformance :
>>>> >
>>>> > class Child: SomeProtocol1, SomeProtocol2
>>>> >
>>>> >
>>>> > 3. class inheritance + conformance :
>>>> >
>>>> > class Child:: BaseClass : SomeProtocol1, SomeProtocol2
>>>> >
>>>> >
>>>> > 4. protocol conformance for structs:
>>>> >
>>>> > struct Struct: SomeProtocol1, SomeProtocol2
>>>> >
>>>> >
>>>> > 5. protocol inheritance:
>>>> >
>>>> > protocol Child:: BaseProtocol1, BaseProtocol2
>>>> >
>>>> >
>>>> >
>>>> > II) in class definition use parenthesis to separate inheritance and
>>>> > conformance :
>>>> >
>>>> >
>>>> > 1. class inheritance :
>>>> >
>>>> > class Child: BaseClass
>>>> >
>>>> >
>>>> > 2. class conformance :
>>>> >
>>>> > class Child: (SomeProtocol1, SomeProtocol2)
>>>> >
>>>> >
>>>> > 3. class inheritance + conformance :
>>>> >
>>>> > class Child: BaseClass (SomeProtocol1, SomeProtocol2)
>>>> >
>>>> >
>>>> > 4. protocol conformance for structs:
>>>> >
>>>> > struct Struct: SomeProtocol1, SomeProtocol2
>>>> >
>>>> > or
>>>> >
>>>> > struct Struct: (SomeProtocol1, SomeProtocol2)
>>>> >
>>>> > should be discussed
>>>> >
>>>> >
>>>> > 5. protocol inheritance:
>>>> >
>>>> > protocol Child: BaseProtocol1, BaseProtocol2
>>>> >
>>>> >
>>>> >
>>>> > III) special word like 'conforms'
>>>> >
>>>> >
>>>> > 1. class inheritance :
>>>> >
>>>> > class Child: BaseClass
>>>> >
>>>> >
>>>> > 2. class conformance :
>>>> >
>>>> > class Child: conforms SomeProtocol1, SomeProtocol2
>>>> >
>>>> > or
>>>> >
>>>> > class Child conforms SomeProtocol1, SomeProtocol2
>>>> >
>>>> >
>>>> > 3. class inheritance + conformance :
>>>> >
>>>> > class Child: BaseClass conforms SomeProtocol1, SomeProtocol2
>>>> >
>>>> >
>>>> > 4. protocol conformance for structs:
>>>> >
>>>> > struct Struct: conforms SomeProtocol1, SomeProtocol2
>>>> >
>>>> > or
>>>> >
>>>> > struct Struct conforms SomeProtocol1, SomeProtocol2
>>>> >
>>>> >
>>>> > 5. protocol inheritance:
>>>> >
>>>> > protocol Child: BaseProtocol1, BaseProtocol2
>>>> >
>>>> >
>>>> >
>>>> > Thoughts?
>>>> >
>>>> > _______________________________________________
>>>> >
>>>> > 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
>>>> >
>>>> _______________________________________________
>>>> 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/20160722/218df70a/attachment.html>