[swift-evolution] [Proposal] Explicit Synthetic Behaviour

[Itai Ferber]

I think there is a bit of confusion here as to what code synthesis does 
— synthesized conformances (whether `Equatable`, `Hashable`, or 
`Codable`) merely provide default implementations for something which 
_already_ conforms to one of these protocols; they do not _add_ 
conformance to types on your behalf.

```swift
struct X {
     let val: Int
}
```

under synthesized `Equatable` does _not_ get an `==` defined for it in 
the same way that it does not get `encode(to:)` or `init(from:)`. Since 
it does not conform to the `Equatable` (or `Codable`) protocol, no 
synthesis happens for it.

As opposed to

```swift
struct Y : Equatable {
     let val: Int
}
```

which would get a default implementation for `static func ==(…)`, 
which it would otherwise already have to implement, by definition.

Synthesis does not add methods on your behalf; it only gives 
implementations for methods you’d have to implement, no matter what. I 
don’t know what’s going on in your case, but it’s not caused by 
synthesis — if your type conforms to `Equatable`, either you would 
have to define `==` yourself, or you’d get a free one. You’d see 
ambiguity regardless, since you asked for the type to be `Equatable` (or 
inherited that requirement).

On 7 Sep 2017, at 10:32, Gwendal Roué via swift-evolution wrote:

> > Le 7 sept. 2017 à 14:37, Matthew Johnson <matthew at anandabits.com> a 
> écrit :
>>
>> I don't understand what this has to do with synthesized Equatable.  
>> Wouldn't manually implemented Equatable have the same impact?  The 
>> design of a DSL should be able to accommodate conformance to basic 
>> protocols without ambiguity.
>
>
> I'll explain you:
>
> The problem with synthesized Equatable is that it adds an unwanted == 
> operator that returns a Bool.
>
> This operator is unwanted because it conflicts with the == operator 
> defined by the DSL which does not return a Bool.
>
> 	// Without synthesised Equatable
> 	let r = (a == b) // the type defined by the DSL
>
> 	// With synthesised Equatable
> 	let r = (a == b) // ambiguous
>
> This is the same kind of conflict that happen when a function is 
> overloaded with two return types:
>
> 	func f() -> Int { ... }
> 	func f() -> String { ... }
> 	f() // ambiguous
>
> Without the synthesized Equatable, the type would not have any == 
> operator that returns a Bool, and thus no conflict with the == 
> operator defined by the DSL (the one that returns an SQL expression, 
> in our particular context).
>
> I hope that I have explained how synthesized conformance may impact 
> code by the mere fact that they define methods. I'm not talking about 
> the correctness of the synthesized code. I'm talking about its mere 
> existence.
>
>> We generally want as many types to be Equatable and Hashable as 
>> possible.  Synthesized conformance means more types will have these 
>> conformance and that's a good thing in all cases (so long as the 
>> implementation is correct).
>
> Sure, of course. I'm with you. I'm not talking against code synthesis. 
> Again, I'm not talking about the correctness either.
>
> I'm talking about the consequences of implicit and non-avoidable 
> synthesis. Exactly the theme of this thread, unless I'm totally 
> mistaken.
>
> Gwendal Roué


> _______________________________________________
> 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/20170907/606f05ea/attachment.html>