I absolutely agree that it's a problem worth solving. However, the question is whether a particular proposed design solves the problem and avoids previously stated weaknesses. What I'm saying here is that, so far, the conversation in this thread has involved reiterating already-proposed designs that have been critiqued. It's really quite tiring for me too to repeat the same critique when someone raises the same proposal a second or third time.
It's possible that it makes sense to have a separate syntax for retroactive modeling. I haven't been able to come up with one that seems reasonable to me, or I would have written to this list to propose it. Do you have such a design in mind? On Fri, Sep 16, 2016 at 16:59 Charles Srstka <[email protected]> wrote: > On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via swift-evolution < > [email protected]> 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. > > Charles > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
