> On Aug 2, 2016, at 12:08 AM, Haravikk <[email protected]> wrote: > >> >> On 1 Aug 2016, at 21:40, Charlie Monroe <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> On Aug 1, 2016, at 10:22 PM, Haravikk via swift-evolution >>> <[email protected] <mailto:[email protected]>> 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.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
