> 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
