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

[Charlie Monroe]

> On Aug 2, 2016, at 12:08 AM, Haravikk <swift-evolution at haravikk.me> wrote:
> 
>> 
>> On 1 Aug 2016, at 21:40, Charlie Monroe <charlie at charliemonroe.net <mailto:charlie at charliemonroe.net>> wrote:
>> 
>>> 
>>> On Aug 1, 2016, at 10:22 PM, Haravikk via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 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.

I've actually re-evaluated my position on this and agree with you when it comes to this issue - I see now that the benefit is minimal and if you don't know the types, it doesn't tell you much anyway. It would tell you when debugging someone elses code since you'd know you should look into parent implementation as well. But since protocols can have default implementation as well, this point is kind of moot.

I'm just opposed to anyone mentioning Xcode here as an argument for or against a language feature/change. You could argue this way that we can keep making code-breaking changes and the IDE will migrate the code for you. While this is true, I remember reading a post from someone on the core team specifically mentioning that the code-breaking changes need to stop in order to spread Swift onto other platforms since not all platforms have Xcode and some are unlikely to even have a decent IDE with even syntax highlighting. Not to mention diffs, Github, etc.

While Xcode (or AppCode) is currently the tool to use at this moment, I feel that some features, where I'm told to "change the syntax highlighting to highlight this, highlight that" in order to compensate are not valid points to the language readability or usability.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160802/fdf20ffd/attachment.html>