[swift-evolution] [Proposal] Explicit Synthetic Behaviour

Haravikk swift-evolution at haravikk.me
Tue Sep 12 11:46:06 CDT 2017


> On 12 Sep 2017, at 16:29, Tony Allevato via swift-evolution <swift-evolution at 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.


More information about the swift-evolution mailing list