Sent from my iPad
> On Dec 31, 2015, at 11:53 AM, Dave Abrahams <dabrah...@apple.com> wrote: > > >> On Dec 31, 2015, at 9:47 AM, Matthew Johnson <matt...@anandabits.com> wrote: >> >>>>>> In the second example here Forwarder does conform to P. The author of >>>>>> Forwarder has the flexibility to specify whether conformance is desired >>>>>> or not. >>>>> >>>>> There are ways to handle that, including factoring the APIs of interest >>>>> out of P and into a private protocol Q, then declaring the Forwardee’s >>>>> conformance to Q. Now, there’s an expressivity problem with our current >>>>> access control system that you can’t use an internal or private protocol >>>>> to provide public API, but that should be fixed separately. >>>> >>>> I'm not sure where Q comes into play in this specific example. The idea >>>> here is that forwarding implementations of all members of P are >>>> synthesized by the forward declaration. It is left up to Forwarder to >>>> decide whether or not to declare actual conformance to P. I am also >>>> confused by "then declaring the Forwardee’s conformance to Q" because we >>>> are discussing Forwarder's conformance here, not Forwardee’s. >>> >>> Presumably both ends of the forwarding arrangement would have to conform to >>> the same protocol, no? >> >> No. This is addressed in the proposal and the lazy collections motivating >> example I replied with last night. I don’t think it’s a good idea to >> require this. > > > My only point was that if we’re going to require the forwarder to conform, we > may as well require it of the forwardee. I realize that you don’t want to > require either conformance. There are independent reasons not to require it of the forwarded and the forwarder, so I disagree with "may as well". It may be possible that eventually enough of the language limitations would be lifted that requiring conformance of both wouldn't restrict the power of a forwarding feature and as such that requirement wouldn't have any downsides other than the need to declare an additional conformance here or there. I would prefer to no artificially restrict the power of the feature without compelling reasons to do so. > > -Dave >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
