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

[Haravikk]

> On 1 Aug 2016, at 21:40, Charlie Monroe <charlie at charliemonroe.net> wrote:
> 
>> 
>> On Aug 1, 2016, at 10:22 PM, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On 1 Aug 2016, at 19:05, Goffredo Marocchi via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 31 Jul 2016, at 21:19, Sean Alling via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> I disagree with this suggestion.  Both a protocol conformance & class inheritance define behavior conformance.  If anything the protocol is more explicitly shown because the required properties and methods are conformed to within its declaration.
>>> 
>>> Especially in a language without abstract classes, inheritance and protocol conformance have a quite important distinction: protocols are about decoupling concrete implementation from behaviour which is not what inheritance allows or promises.
>> 
>> But is it a big enough case for its own syntax? I've had to work quite hard to break myself of old OOP habits, but I've now gotten pretty good at using protocols with extensions to do much of what I used abstract classes and such for (took a while though).
>> 
>> Even when I do use classes with inheritance, unless it's a very simple type I don't usually define protocol conformance as part of the type declaration, so I know the only thing up there will be inheritance; I put all my protocol conformances into extensions.
>> 
>> Also, I don't think it's that hard to figure out what a type represents, as you can alt-click in Xcode to quickly find out whether a type is a class or a protocol, and of course class inheritance is only possible on classes.
> 
> Xcode (or any other IDE) is not part of the language. Many people here are still forgetting that. Saying that it's not an issue, since Xcode will do this, will highlight that. Github doesn't have an Option-Click. Neither do any other SCM-tools. Try to browse the stdlib on Github using a person seeing the code for the first time.
> 
> Swift is aiming to be cross-platform - any argument that Xcode (or any other IDE) can do something is IMHO irrelevant.

And? I was just pointing out that it can be easy to find out the type is in Xcode, the important part is the end; inheritance is only possible on a class, and in Swift structs are generally preferred wherever possible, so classes shouldn't (ideally) be very common. This means the types that you are extending aren't especially common either; if you both inherit from and conform to a bunch of things that the developer doesn't recognise, then I don't think a syntax separating them makes much of a difference, while if they know most or all of them then they know which is which. Plus like I say there are patterns to make it even easier, with inheritance always first and/or protocol conformance in extensions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160801/ed8610a5/attachment.html>