> On 12 Sep 2017, at 16:29, Tony Allevato via swift-evolution > <swift-evolution@swift.org> wrote: > > Since your game involves the specific question of a property that should not > be considered for Equatable synthesis, and since SE-0185 explicitly calls out > the notion of transient properties as a future direction to solve that > specific problem, then my solution is "I declare the property as transient." > > Surely this is an acceptable solution? It achieves the goal you set, and more > concisely/quickly than the ways you proposed in that post. It doesn't require > me to go fishing through code; the act of adding the property and making it > transient is completely localized to one place (it's one line!). If there's a > synthesized implementation of Equatable, then the property gets ignored as > desired. If there's a handwritten implementation, then the new property is > already ignored because it wasn't there to begin with, but the transient > declaration still provides valuable information to the reader of the code > about the intention. > > If the rebuttal to that is going to be "a developer may not know about > transient", then where do we draw the line at expecting users to know how to > use the features their language? It's a significant leap to go from > "developers might do the wrong thing" to "so this specific approach is the > only right way to fix it."
I think that it's reasonable to assume that the protocol would inform developers of the use of transient, but this comes back to the original topic of this thread; if the developer didn't ask for the synthesised behaviour then is it reasonable to assume they'll have properly marked their properties as transient? My argument would (perhaps unsurprisingly) be no; a default implementation that can make use of attributes is IMO something that a developer should opt into explicitly as a convenient alternative to providing a full implementation themselves. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
