We can override the protocol default implementation in the extension, but the issue I see with default implementation in Swift is that if I pass the object created this way around in a type erased container (Any : Protocol1 like it was common for many to pass id<Protocol> around in the Objective-C days, a good practice IMHO) then my overrode would not be called, but the default implementation will be used instead. I would be far more comfortable with this “magic” provided for free of default implementations were dynamically dispatched.
Sent from my iPhone > On 19 Aug 2017, at 19:06, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Sat, Aug 19, 2017 at 06:07 Haravikk via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>>> On 19 Aug 2017, at 11:44, Tino Heth <2...@gmx.de> wrote: >>>> Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution >>>> <swift-evolution@swift.org>: >>>> For me the whole point of a basic protocol is that it forces me to >>>> implement some requirements in order to conform; I can throw a bunch of >>>> protocols onto a type and know that it won't compile until I've finished >>>> it, developers get distracted, leave things unfinished to go back to >>>> later, make typos etc. etc. To me declaring a conformance is a declaration >>>> of "my type will meet the requirements for this make, sure I do it", not >>>> "please, please use some magic to do this for me"; there needs to be a >>>> clear difference between the two. >>> >>> My conclusion isn't as pessimistic as yours, but I share your objections: >>> Mixing a normal feature (protocols) with compiler magic doesn't feel right >>> to me — wether it's Equatable, Hashable, Codable or Error. >>> It's two different concepts with a shared name*, so I think even >>> AutoEquatable wouldn't be the right solution, and something like #Equatable >>> would be a much better indicator for what is happening. >>> >>> Besides that specific concern, I can't fight the feeling that the evolution >>> process doesn't work well for proposals like this: >>> It's a feature that many people just want to have as soon as possible, and >>> concerns regarding the long-term effects are more or less washed away with >>> eagerness. >>> >>> - Tino >>> >>> * for the same reason, I have big concerns whenever someone proposes to >>> blur the line between tuples and arrays >> >> Agreed. To be clear though; in spite of my pessimism this is a feature that >> I do want, but I would rather not have it at all than have it implemented in >> a way that hides bugs and sets a horrible precedent for the future. > > This was already touched upon during review, but to reiterate, the analogy to > default protocol implementations is meant specifically to address this point > about "hiding bugs." Yes, this feature cannot currently be implemented as a > default protocol implementation without magic; with better reflection > facilities there's a good chance that one day it might be, but that's not the > reason why it's being compared to default protocol implementations. The > reason for the comparison is that this feature only "hides bugs" like a > default protocol implementation "hides bugs" (in the > I-conformed-my-type-and-forgot-to-override-the-default-and-the-compiler-won't-remind-me-anymore > sense of "hiding bugs"), and the addition of default protocol > implementations, unless I'm mistaken, isn't even considered an API change > that requires Swift Evolution review. > > Given Swift's emphasis on progressive disclosure, I'm fairly confident that > once reflection facilities and/or code-generation facilities improve, many > boilerplate-y protocol requirements will be given default implementations > where they cannot be written today. With every advance in expressiveness, > more protocol requirements that cannot currently have a default > implementation will naturally acquire them. Since the degree to which the > compiler will cease to give errors about non-implementation is directly in > proportion to the boilerplate reduced, it's not a defect but a feature that > these compiler errors go away. At the moment, it is a great idea to enable > some of these improvements for specific common use cases before the general > facilites for reflection and/or code-generation are improved in later > versions of Swift, since the user experience would be expected to remain the > same once those full facilities arrive. > >> I realise I may seem to be overreacting, but I really do feel that strongly >> about what I fully believe is a mistake. I understand people's enthusiasm >> for the feature, I do; I hate boilerplate as much as the next developer, but >> as you say, it's not a reason to rush forward, especially when this is not >> something that can be easily changed later. >> >> That's a big part of the problem; the decisions here are not just about >> trimming boilerplate for Equatable/Hashable, it's also about the potential >> overreach of every synthesised feature now and in the future as well. >> _______________________________________________ >> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
