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

David Hart david at hartbit.com
Fri Jul 22 10:42:55 CDT 2016 

> On 22 Jul 2016, at 17:06, Brandon Knope via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I guess my question comes down to this:
> 
> Is this a change for consistency OR is there actually a tangible benefit?

I see a fairly straightforward benefit. When studying new code, you want to get an idea for the class inheritance tree and the OP wants to make it clear when you are inheriting and what the class is.

> If it's a protocol: you know some methods are being implemented.
> If it's a base class: it's possible that some methods are overridden
> 
> Between knowing these two things, what does the distinction *actually* bring about?
> 
> It's very possible I am not explaining myself properly. 
> 
> Another way: so now you know it is most definitely a base class and not a protocol, what does this information allow you to do differently?
> 
> Basically, I am for introducing an "implements" or some new syntax for this distinction, but I just want to know if this change is just for consistency to separate inheritance and conformance OR if there is truly a benefit to knowing this distinction. 
> 
> I think this is important to convince people to make a change like this. I understand the idea behind it but the important question is: why?
> 
> Thanks,
> Brandon 
> 
>> On Jul 22, 2016, at 10:52 AM, Vladimir.S <svabox at gmail.com> wrote:
>> 
>> I don't understand the question, really. I need to know because I need to know :-)
>> I.e. I see new code, I'm trying to understand the structure of the class, its dependency, if all the base code of this class is inside this class or there is some 'base' code that is overriden, etc.. Class and Protocol two different entities with their specifics, so I need to know how the class is composed, if some methods without `override` keyword could be required by protocol..
>> All the basic things you need to know about the new class you found in some code. No?
>> 
>> Can I live with current syntax? Yes. Will change make a code more understandable for viewer in area of inheritance/conformance - Yes, especially if you need to review the code not in XCode/IDE but in some other viewer/web page. Should we make this change? I believe yes, but probably I'm not right in my opinion, so we discussing it here.
>> 
>>> On 22.07.2016 17:32, Brandon Knope wrote:
>>> I understand.
>>> 
>>> But why would you need to know if it's a class or a protocol to use the
>>> type? What understanding comes from knowing this information?
>>> 
>>> I am honestly trying to understand the problem here and it feels like I'm
>>> overlooking something.
>>> 
>>> Brandon
>>> 
>>> On Jul 22, 2016, at 10:12 AM, Charlie Monroe <charlie at charliemonroe.net
>>> <mailto:charlie at charliemonroe.net>> wrote:
>>> 
>>>> Coming to someone elses code, it adds an extra effort to understand the
>>>> declaration. Putting inheritance and conformance separately makes the
>>>> declaration easier to read. At least for me.
>>>> 
>>>>> On Jul 22, 2016, at 4:05 PM, Brandon Knope <bknope at me.com
>>>>> <mailto:bknope at me.com>> wrote:
>>>>> 
>>>>> Honest question: what is actually confusing about the current behavior?
>>>>> 
>>>>> I.E. What is important about knowing whether "DataSource" is a class or
>>>>> a protocol?
>>>>> 
>>>>> I thought the blurred distinction was intentional?
>>>>> 
>>>>> Brandon
>>>>> 
>>>>>> On Jul 22, 2016, at 9:47 AM, Charlie Monroe via swift-evolution
>>>>>> <swift-evolution at swift.org <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160722/2f4f0f04/attachment.html>

More information about the swift-evolution mailing list