On Tue, Sep 12, 2017 at 00:06 Gwendal Roué via swift-evolution < swift-evolution@swift.org> wrote:
> >> This doesn't align with how Swift views the role of protocols, though. >> One of the criteria that the core team has said they look for in a protocol >> is "what generic algorithms would be written using this protocol?" >> AutoSynthesize doesn't satisfy that—there are no generic algorithms that >> you would write with AutoEquatable that differ from what you would write >> with Equatable. >> >> >> And so everybody has to swallow implicit and non-avoidable code synthesis >> and shut up? >> > > That's not what I said. I simply pointed out one of the barriers to > getting a new protocol added to the language. > > Code synthesis is explicitly opt-in and quite avoidable—you either don't > conform to the protocol, or you conform to the protocol and provide your > own implementation. What folks are differing on is whether there should > have to be *two* explicit switches that you flip instead of one. > > > No. One does not add a protocol conformance by whim. One adds a protocol > conformance by need. So the conformance to the protocol is a *given* in our > analysis of the consequence of code synthesis. You can not say "just don't > adopt it". > > As soon as I type the protocol name, I get synthesis. That's the reason > why the synthesized code is implicit. The synthesis is explicitly written > in the protocol documentation, if you want. But not in the programmer's > code. > > I did use "non-avoidable" badly, you're right: one can avoid it, by > providing its custom implementation. > > So the code synthesis out of a mere protocol adoption *is* implicit. > > Let's imagine a pie. The whole pie is the set of all Swift types. Some > slice of that pie is the subset of those types that satisfy the conditions > that allow one of our protocols to be synthesized. Now that slice of pie > can be sliced again, into the subset of types where (1) the synthesized > implementation is correct both in terms of strict value and of business > logic, and (2) the subset where it is correct in terms of strict value but > is not the right business logic because of something like transient data. > > > Yes. > > What we have to consider is, how large is slice (2) relative to the whole > pie, *and* what is the likelihood that developers are going to mistakenly > conform to the protocol without providing their own implementation, *and* > is the added complexity worth protecting against this case? > > > That's quite a difficult job: do you think you can evaluate this > likelihood? > > Explicit synthesis has big advantage: it avoids this question entirely. > > Remember that the main problem with slide (2) is that developers can not > *learn* to avoid it. > > For each type is slide (2) there is a probability that it comes into > existence with a forgotten explicit protocol adoption. And this probability > will not go down as people learn Swift and discover the existence of slide > (2). Why? because this probability is driven by unavoidable human behaviors: > - developer doesn't see the problem (a programmer mistake) > - the developper plans to add explicit conformance later and happens to > forget (carelessness) > - a developper extends an existing type with a transient property, and > doesn't add the explicit protocol conformance that has become required. > > Case 2 and 3 bite even experienced developers. And they can't be improved > by learning. > > Looks like the problem is better defined as an ergonomics issue, now. > > If someone can show me something that points to accidental synthesized > implementations being a significant barrier to smooth development in Swift, > I'm more than happy to consider that evidence. But right now, this all > seems hypothetical ("I'm worried that...") and what's being proposed is > adding complexity to the language (an entirely new axis of protocol > conformance) that would (1) solve a problem that may not exist to any great > degree, and (2) does not address the fact that if that problem does indeed > exist, then the same problem just as likely exists with certain > non-synthesized default implementations. > > > There is this sample code by Thorsten Seitz with a cached property which > is quite simple and clear : > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170911/039684.html > > This is the sample code that had me enter the "worried" camp. > Sorry, I fail to see what the problem is in that example. A method was invoked that changed a stored property of one instance. Therefore, it’s no longer equal to the other instance. If you want a custom notion of equality, you should implement it yourself. In the absence of such, the _default_ notion of equality is pretty clear. > Gwendal > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution