[swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Tony Allevato]

On Tue, Sep 12, 2017 at 8:10 AM Gwendal Roué <gwendal.roue at gmail.com> wrote:

> >> There is this sample code by Thorsten Seitz with a cached property
> which is quite simple and clear :
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170911/039684.html
> >>
> >> This is the sample code that had me enter the "worried" camp.'
> >>
> > I really like Thorsten's example, because it actually proves that
> requiring explicit derivation is NOT the correct approach here. (Let's set
> aside the fact that Optionals prevent synthesis because we don't have
> conditional conformances yet, and assume that we've gotten that feature as
> well for the sake of argument.)
> >
> > Let's look at two scenarios:
> >
> > 1) Imagine I have a value type with a number of simple Equatable
> properties. In a world where synthesis is explicit, I tell that value type
> to "derive Equatable". Everything is fine. Later, I decide to add some
> cache property like in Thorsten's example, and that property just happens
> to also be Equatable. After doing so, the correct thing to do would be to
> remove the "derive" part and provide my custom implementation. But if I
> forget to do that, the synthesized operator still exists and applies to
> that type. If you're arguing that "derive Equatable" is better because its
> explicitness prevents errors, you must also accept that there are possibly
> just as many cases where that explicitness does *not* prevent errors.
>
> It looks like it is true, but it is not. The implicit world is harder to
> deal with. And this is because in the implicit world, you never know if
> conformance has been synthesized or not. In the explicit world, you know:
> it's plain written down.
>
> To see this point, please play the game I've proposed to Xiaodi at
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170911/039710.html


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."



> > 2) Imagine I have a value type with 10 Equatable properties and one
> caching property that also happens to be Equatable. The solution being
> proposed here says that I'm better off with explicit synthesis because if I
> conform that type to Equatable without "derive", I get an error, and then I
> can provide my own custom implementation.
>
> Yes.
>
> > But I have to provide that custom implementation *anyway* to ignore the
> caching property even if we don't make synthesis explicit. Making it
> explicit hasn't saved me any work—it's only given me a compiler error for a
> problem that I already knew I needed to resolve.
>
> Oh, so compiler errors and warnings bring no information to you? :-) I'm
> impressed, but I'll keep on focusing on designing a language for average
> developpers, not only geniuses.
>
> Replay your argument and imagine that compiler outputs are useful to you.
> This will change your conclusion.
>
> Gwendal
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170912/e01e5d3e/attachment.html>