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 <matt...@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
