[swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Xiaodi Wu]

On Tue, Sep 12, 2017 at 00:06 Gwendal Roué via swift-evolution <
swift-evolution at swift.org> wrote:

>
>> This doesn't align with how Swift views the role of protocols, though.
>> One of the criteria that the core team has said they look for in a protocol
>> is "what generic algorithms would be written using this protocol?"
>> AutoSynthesize doesn't satisfy that—there are no generic algorithms that
>> you would write with AutoEquatable that differ from what you would write
>> with Equatable.
>>
>>
>> And so everybody has to swallow implicit and non-avoidable code synthesis
>> and shut up?
>>
>
> That's not what I said. I simply pointed out one of the barriers to
> getting a new protocol added to the language.
>
> Code synthesis is explicitly opt-in and quite avoidable—you either don't
> conform to the protocol, or you conform to the protocol and provide your
> own implementation. What folks are differing on is whether there should
> have to be *two* explicit switches that you flip instead of one.
>
>
> No. One does not add a protocol conformance by whim. One adds a protocol
> conformance by need. So the conformance to the protocol is a *given* in our
> analysis of the consequence of code synthesis. You can not say "just don't
> adopt it".
>
> As soon as I type the protocol name, I get synthesis. That's the reason
> why the synthesized code is implicit. The synthesis is explicitly written
> in the protocol documentation, if you want. But not in the programmer's
> code.
>
> I did use "non-avoidable" badly, you're right: one can avoid it, by
> providing its custom implementation.
>
> So the code synthesis out of a mere protocol adoption *is* implicit.
>
> Let's imagine a pie. The whole pie is the set of all Swift types. Some
> slice of that pie is the subset of those types that satisfy the conditions
> that allow one of our protocols to be synthesized. Now that slice of pie
> can be sliced again, into the subset of types where (1) the synthesized
> implementation is correct both in terms of strict value and of business
> logic, and (2) the subset where it is correct in terms of strict value but
> is not the right business logic because of something like transient data.
>
>
> Yes.
>
> What we have to consider is, how large is slice (2) relative to the whole
> pie, *and* what is the likelihood that developers are going to mistakenly
> conform to the protocol without providing their own implementation, *and*
> is the added complexity worth protecting against this case?
>
>
> That's quite a difficult job: do you think you can evaluate this
> likelihood?
>
> Explicit synthesis has big advantage: it avoids this question entirely.
>
> Remember that the main problem with slide (2) is that developers can not
> *learn* to avoid it.
>
> For each type is slide (2) there is a probability that it comes into
> existence with a forgotten explicit protocol adoption. And this probability
> will not go down as people learn Swift and discover the existence of slide
> (2). Why? because this probability is driven by unavoidable human behaviors:
> - developer doesn't see the problem (a programmer mistake)
> - the developper plans to add explicit conformance later and happens to
> forget (carelessness)
> - a developper extends an existing type with a transient property, and
> doesn't add the explicit protocol conformance that has become required.
>
> Case 2 and 3 bite even experienced developers. And they can't be improved
> by learning.
>
> Looks like the problem is better defined as an ergonomics issue, now.
>
> If someone can show me something that points to accidental synthesized
> implementations being a significant barrier to smooth development in Swift,
> I'm more than happy to consider that evidence. But right now, this all
> seems hypothetical ("I'm worried that...") and what's being proposed is
> adding complexity to the language (an entirely new axis of protocol
> conformance) that would (1) solve a problem that may not exist to any great
> degree, and (2) does not address the fact that if that problem does indeed
> exist, then the same problem just as likely exists with certain
> non-synthesized default implementations.
>
>
> 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.
>

Sorry, I fail to see what the problem is in that example. A method was
invoked that changed a stored property of one instance. Therefore, it’s no
longer equal to the other instance. If you want a custom notion of
equality, you should implement it yourself. In the absence of such, the
_default_ notion of equality is pretty clear.


> Gwendal
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170912/9c8ef7a9/attachment.html>