On Sat, Aug 19, 2017 at 1:13 PM, Goffredo Marocchi <[email protected]> wrote:
> 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. > Are you referring to protocol extension methods? Those are not default implementations, do not have a corresponding protocol requirement that can be overridden, and are not what's being discussed here. Sent from my iPhone > > On 19 Aug 2017, at 19:06, Xiaodi Wu via swift-evolution < > [email protected]> wrote: > > > On Sat, Aug 19, 2017 at 06:07 Haravikk via swift-evolution < > [email protected]> wrote: > >> >> On 19 Aug 2017, at 11:44, Tino Heth <[email protected]> wrote: >> >> Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution < >> [email protected]>: >> >> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
