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

[Vladimir.S]

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