<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 6 Sep 2017, at 01:36, Robert Bennett <<a href="mailto:rltbennett@icloud.com" class="">rltbennett@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""></div><div class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">I take issue with the fact that this problem is no different from accidentally gaining the default inheritance of *any* member required by a protocol and implemented in an extension of that protocol. The fact that in this case conformance is synthesized by the compiler instead of written in source code somewhere is immaterial; in principle, nothing is (was?) stopping the same default implementation from being implemented with a Mirror instead of the current approach.</span></div></div></div></div></blockquote><div><br class=""></div><div>This is why I'm proposing that Mirrors of `self` should likewise require the new attribute; while I realise it may be possible to sneak self-reflection in somehow regardless by tricking the compiler, this should at least pick up the most obvious cases. A more complete solution could possibly just consider <b class="">all</b> use of reflection to be synthetic, requiring methods callable from protocol extensions (global functions, static methods etc.) to use the attribute as well, so that the compiler can detect any function call with `self` that could potentially result in reflective behaviour.</div><div><br class=""></div><div>The issue here isn't that there might be other ways to do it (these can be addressed), it's that all methods of doing this should require developers to explicitly opt-in, otherwise it leads to potential bugs and/or unwanted behaviour. It's also IMO a gross overreach for protocols to begin with, and sets a dangerous precedent for a language that's supposed to be about safety and prevention of bugs, especially when in the case of Equatable and Hashable it will actually <b class="">hide</b> bugs that are currently caught.</div><div><br class=""></div><div>As a general rule I would argue that Mirrors should almost never be used for any purpose, except perhaps debugging; in production code they can lead to subtle and misleading problems, not to mention any performance impacts. Even for things like serialising types, it is not a desirable way to do it, and should only be used as a last resort because of missing features in Swift.</div><br class=""><blockquote type="cite" class=""><div dir="auto" class=""><div class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">I still think that the role keyword proposal is the best solution to this problem proposed so far. </span><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170612/037484.html" class="" style="background-color: rgba(255, 255, 255, 0);">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170612/037484.html</a></div></div></div></blockquote><div><br class=""></div><div>While I support the idea of these role keywords, they don't solve all of the same problems. Consider for example a missing protocol requirement; currently it is caught if a protocol cannot offer a default implementation for it, however, in the presence of synthetic behaviour it is possible that the requirement is met, but by a method that will not work as desired.</div><div><br class=""></div><div>The main issue here is that we're talking about methods that appear like default implementations, but go well beyond what the protocol itself defines; when you start delving into concrete types from within a protocol you are making assumptions about that concrete type that simply <b class="">cannot</b> be guaranteed. Any mistake or omission by a developer could lead to behaviour they do not want, and that may not be easy to debug, and in the case of Equatable and Hashable is a potential bug that is currently impossible.</div><br class=""><blockquote type="cite" class=""><div dir="auto" class=""><div class=""><blockquote type="cite" class="">On Sep 5, 2017, at 4:02 PM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">Some of you will have seen my impassioned pleas on the synthesised Equatable/Hashable thread against implementing implicit synthesised behaviour on protocols that must, by necessity, make assumptions about a concrete type that could be incorrect.</blockquote></div><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">For those that haven't, the concept of synthetic behaviour in discussion here is essentially any kind of default behaviour for a protocol that is automatically generated based upon the concrete type itself (rather than just what the protocol defines). Currently this refers to compiler magic as proposed for Codable, Equatable and Hashable, but also includes the reflection API and any future native macro support for Swift. Using any of these to implement default methods for protocols should IMO be made explicit to developers using any such protocol so that they can specifically opt-in to the behaviour only if they want to and understand what it does.</div><div class=""><br class=""></div><div class="">This proposal idea is essentially for a new attribute @synthetic (name is up for debate). This attribute is required for any default implementation that includes reflective type compiler magic, use of the reflection API against `self` or, in future, any native Swift macros within the method (possibly limited to specific features, will depend on the macro language and its capabilities). If a default method does not have this attribute, then the compiler will produce an error with the appropriate fix-it. For convenience this attribute can be applied to any extension block or even a protocol definition in order to mark <b class="">all</b> methods in that block/type as synthetic, though it's worth noting that doing so will prevent these default implementations from being provided if they don't actually need this attribute.</div><div class=""><br class=""></div><div class="">Basically the intention is that any protocol default implementation that requires more knowledge about the concrete type than merely what the protocol (and its parents) provide direct access to, <b class="">must</b> be marked as synthetic.</div><div class=""><br class=""></div><div class="">To use the synthetic behaviour of a protocol, developers must then use the @synthetic keyword when conforming to it, explicitly indicating that they want the extra behaviours rather than implementing the method(s) for themselves. To ignore the synthetic behaviour (and thus require some kind of manual implementation of methods as normal), simply omit the keyword:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>struct Foo : @synthetic Equatable { var someData:String }</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Type fully conforms to Equatable using synthetic behaviour (equatable properties must be equal)</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>struct Foo : Equatable { var someData:String }</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Error due to unimplemented methods, but offers @synthetic as a fix-it if all unimplemented methods are @synthetic</font></div><div class=""><br class=""></div><div class="">It is possible that the attribute could be expanded to have parameters, allowing for synthetic conformance only on specific methods, but I'm unsure if that'd be the best way to do it, or how likely that is to be needed.</div><div class=""><br class=""></div><div class="">With this kind of explicit declaration it becomes obvious within code when a developer is specifically choosing to benefit from synthetic behaviour; this hopefully makes it more likely that a developer will fully consider what the implications of this may be, rather than doing it accidentally. The idea in part is to distinguish such types as having separate protocol and synthesised behaviour, where conformance without the @synthetic attribute specifically requires that all protocol requirements be met in full, and that any default behaviour is implemented only on the basis of the protocol itself, while adding @synthetic identifies that more invasive automated behaviour is permitted/requested.</div><div class=""><br class=""></div><div class="">At this stage I don't think there should be much of an impact for existing code; as far as I can tell it should only affect any protocols that happen to be using Mirror(reflecting: self) for some reason within a default implementation, which I can't imagine represents a huge subsection of existing code, and the fix is the simple addition of an attribute.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Anyway, this is basically just a rough dump of the ideas for how the synthesised Codable, Equatable and Hashable behaviours (and anything else anyone can think of) should be changed before Swift 4 is released. I'm hoping for feedback before I make a formal proposal as I don't have a lot of time at the moment, so am looking to do the more structured document once stuff has been hammered out a bit.</div></div></blockquote></div></blockquote></div></body></html>