>
>> 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
<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.
Gwendal
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
