> Am 26.05.2016 um 17:35 schrieb Matthew Johnson <[email protected]>:
>
>
>> On May 26, 2016, at 10:18 AM, T.J. Usiyan via swift-evolution
>> <[email protected]> wrote:
>>
>> +1 to a `deriving` keyword
>
> + 1. I like it as well. It makes the feature opt-in, declaring conformance
> and requesting synthesis at the same time. The syntactic difference from a
> simple conformance declaration means manual conformance can still be checked
> properly with no ambiguity about whether you were requesting synthesis or
> not. This approach also generalizes well.
>
> This bullet makes me uncomfortable though:
>
>> - It is compatible with generics. E.g. `struct Shape<T> deriving Equatable`
>> will make every `Shape<X>` equatable if `X` is equatable. But if `X` is not
>> equatable, `Shape<X>` can be used as well.
>
> You should not be able to just say `struct Shape<T> deriving Equatable`. You
> should have to do this:
>
> extension Shape deriving Equatable where T: Equatable {}
>
> Or some equivalent syntax that makes it clear that you only intend to derive
> equatable when T meets the stated conditions.
I agree that this might be a problem that needs some consideration. The
difference in Haskell is that type declarations are usually very short, e.g.
data Maybe a = Nothing | Just a deriving (Eq, Ord)
and to any sane reader it is obvious, that if `a` is not in `Eq`, then `Maybe
a` is not in `Eq` as well. Having to write something like
data Maybe a = Nothing | Just a deriving ({Eq where Eq a}, {Ord where Ord
a})
would produce no benefit. The situation is a bit different in Swift, because
type declarations are usually much larger. On the other hand, Generics are less
important in Swift than they are in Haskell, so having a slightly more awkward
syntax when using it in a generic way is not that bad. Maybe we could say
struct Shape<T> deriving Eq? { ... }
and the "?" after Eq means "if possible"? To opt-in for "derive if you can"
behavior? However, I would like to see an example where the "derive if you can"
behavior would lead to problems / confusing language semantics. I'm not saying
that there is no such example, I just cannot think of one currently. The worst
that can happen is that the developer is surprised that a particular type is
not equatable, even though he has "derived" an Equatable "instance". He will
find out at compile time I guess, and Stackoverflow will have the answer
("swift deriving doesn't work"). But still, the question is also how obvious
the requirements for a type are for `deriving Equatable` to work well.
-Michael
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
