[swift-evolution] Mark protocol methods with their protocol

[Xiaodi Wu]

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 <cocoadev at charlessoft.com>
wrote:

> On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at 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.
>
> Charles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160916/c0166fb9/attachment.html>