On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via swift-evolution 
<swift-evolution@swift.org> wrote:
> We've had this discussion on the list multiple times already. The gist of the 
> difficulty here is that most proposals for a mandatory keyword don't permit 
> retroactive modeling, so it's a no-go. On the other hand, the core team seems 
> to take a dim view to optional syntax, since that's more in the ballpark of 
> linters.

Numerous solutions to your objection have been proposed; you always simply 
dismiss all of them in favor of your dogmatic stance. It’s really quite tiring. 
You can have this and support retroactive modeling; you just might need to have 
a separate syntax for retroactive conformances. You keep bringing that up as a 
hard-and-fast objection, but you know what? Maybe retroactive conformances 
should have a separate syntax, because they’re not saying the same thing! One 
is saying "here are some methods that will make this type conform to this 
protocol”, where the other is saying “this type already has the methods that 
conform to this protocol somewhere.” These are not the same thing, and it might 
be confusing to see a conformance declaration and assume it’s the former when 
it’s actually the latter, and then have trouble finding the conformances. Maybe 
it would actually make your code clearer if retroactive conformances were 
required to declare “this method exists somewhere else already.” Maybe you 
could even command-click on it and jump to the actual declaration. Anything 
would be better than the current situation, because:

The reason this keeps coming up is because it’s a real problem. I myself have 
started taking up the practice of always using copy-and-paste to declare 
conformances to protocols, because otherwise the chances of mistyping something 
and having the bug not manifest itself until runtime is simply too high. This 
is not a “linter” problem; this affects basic functionality and makes 
protocols, honestly, really dangerous to use. For a language that bills itself 
as “protocol-oriented”, it’s really quite damning that its protocol support is 
this brittle and fragile compared to its support for traditional inheritance. 
I’ve been bitten by this enough times by now to somewhat regret the decision to 
go with a protocol-based design. This is a real shame because conceptually, the 
idea of Swift’s protocol-based design is really cool.


swift-evolution mailing list

Reply via email to