Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[L. Mihalkovic via swift-evolution]

If Swift is to be used for serious data handling, might as well learn from the 
java early errors and directly go highly optimized intrinsic code for this type 
of features: even phones have very good vectorized instructions ... would be 
tragic to use run of the mill gereral purpose code instead

On May 31, 2016, at 9:03 AM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> I'm not a fan of AutoEquatable or AutoHashable. These protocols suggest that 
>> automatic conformance can be defined in the language itself and that derived 
>> protocol instances don't have to be implemented as compiler intrinsics. 
>> That's just not the case. You cannot define something like
>> 
>> @auto protocol AutoEquatable : Equatable {
>>  ...
>> }
>> 
>> because what would you write instead of "..."? Copy Lisp-Macros? Copy 
>> Template-Haskell? I don't really need to disagree here, I could just say 
>> "good idea, do you want to make a proposal for this?" and then I will never 
>> hear again anything from this idea, because no one will be able to write the 
>> "detailed design" section of that proposal. (at least, I don't know how to 
>> design such a feature; the solution space looks empty to me. there are 
>> similar issues with "property behaviors" IMHO, but that's another story.)
> 
> Actually, I believe you could write a version of AutoEquatable merely by 
> adding a couple items from the generics manifesto:
> 
>protocol AutoEquatable: Equatable {}
>
>func ==  (lhs: T, rhs: T) -> Bool {
>let lhsMirror = Mirror(reflecting: lhs)
>let rhsMirror = Mirror(reflecting: rhs)
>
>for ((lhsLabel, lhsValue), (rhsLabel, rhsValue)) in zip(lhs.children, 
> rhs.children) {
>guard lhsLabel == rhsLabel else { return false }
>
>guard let lhsValue = (lhsValue as! Equatable) openas U else { 
> return false }
>guard let rhsValue = rhsValue as? U else { return false }
>guard lhsValue == rhsValue else { return false }
>}
>
>return true
>}
> 
> This is not the all-powerful code-generation-based solution everyone's pining 
> for, of course. But (modulo a few bugs stemming from this being a proof of 
> concept) it *would* work. If the compiler occasionally decides to write a 
> more specialized equivalent, well, that's its prerogative, right?
> 
> (In a recent thread on property reflection, I discussed the possibility of 
> attaching lists of properties to types, with property behaviors being used to 
> add properties to the lists. That would actually work better than `Mirror` 
> for this task, but it's a more speculative feature.)
> 
> As for an eventual compile-time-generated implementation, well, that kind of 
> thing *does* seem to be on the design team's radar. We've already seen a 
> concrete proposal along those lines in property behaviors; I could imagine a 
> "type behaviors" feature being introduced in the future which could 
> introspect a type and generate new members based on what it sees. And 
> generalized hygienic macros keep coming up too. Just because they aren't in 
> Swift 3 doesn't mean we can't design as though they'll be here eventually.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Brent Royal-Gordon via swift-evolution]

> I'm not a fan of AutoEquatable or AutoHashable. These protocols suggest that 
> automatic conformance can be defined in the language itself and that derived 
> protocol instances don't have to be implemented as compiler intrinsics. 
> That's just not the case. You cannot define something like
> 
> @auto protocol AutoEquatable : Equatable {
>   ...
> }
> 
> because what would you write instead of "..."? Copy Lisp-Macros? Copy 
> Template-Haskell? I don't really need to disagree here, I could just say 
> "good idea, do you want to make a proposal for this?" and then I will never 
> hear again anything from this idea, because no one will be able to write the 
> "detailed design" section of that proposal. (at least, I don't know how to 
> design such a feature; the solution space looks empty to me. there are 
> similar issues with "property behaviors" IMHO, but that's another story.)

Actually, I believe you could write a version of AutoEquatable merely by adding 
a couple items from the generics manifesto:

protocol AutoEquatable: Equatable {}

func ==  (lhs: T, rhs: T) -> Bool {
let lhsMirror = Mirror(reflecting: lhs)
let rhsMirror = Mirror(reflecting: rhs)

for ((lhsLabel, lhsValue), (rhsLabel, rhsValue)) in 
zip(lhs.children, rhs.children) {
guard lhsLabel == rhsLabel else { return false }

guard let lhsValue = (lhsValue as! Equatable) openas U 
else { return false }
guard let rhsValue = rhsValue as? U else { return false 
}
guard lhsValue == rhsValue else { return false }
}

return true
}

This is not the all-powerful code-generation-based solution everyone's pining 
for, of course. But (modulo a few bugs stemming from this being a proof of 
concept) it *would* work. If the compiler occasionally decides to write a more 
specialized equivalent, well, that's its prerogative, right?

(In a recent thread on property reflection, I discussed the possibility of 
attaching lists of properties to types, with property behaviors being used to 
add properties to the lists. That would actually work better than `Mirror` for 
this task, but it's a more speculative feature.)

As for an eventual compile-time-generated implementation, well, that kind of 
thing *does* seem to be on the design team's radar. We've already seen a 
concrete proposal along those lines in property behaviors; I could imagine a 
"type behaviors" feature being introduced in the future which could introspect 
a type and generate new members based on what it sees. And generalized hygienic 
macros keep coming up too. Just because they aren't in Swift 3 doesn't mean we 
can't design as though they'll be here eventually.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Mark Sands via swift-evolution]

In light of Chris and Dave's responses about how this discussion will be mostly 
absent of core team members until Swift 3 is more or less wrapped up, perhaps 
we should let this thread sit idle until then. As the original necromancer, I'm 
sure this will be brought back to life when it's appropriate.

Mark

> On May 30, 2016, at 18:23, Patrick Smith via swift-evolution 
>  wrote:
> 
> Yes exactly, use the protocol conformance syntax, Michael’s description was 
> mistaken I think.
> 
> Just the same way you get protocol extensions without having to use a special 
> keyword.
> 
> 
>> On 31 May 2016, at 6:26 AM, Vladimir.S via swift-evolution 
>>  wrote:
>> 
>> I see these two groups: both wants explicit conformance to protocols, but 
>> first thinks that current syntax is enough (`: Equatable`) and second thinks 
>> we should introduce new keyword `deriving` for this(`: deriving Equatable`). 
>> I see no opinions(except the one opinion in proposal itself) to 
>> automatically deriving without explicit decoration.
>> 
>>> On 30.05.2016 22:04, Michael Peternell via swift-evolution wrote:
>>> It seems that there are two groups here. 1) Group 1 wants Equatable (and 
>>> others) be derived automatically unless specifically overridden: similar to 
>>> auto-synthesis of properties in Objective-C. 2) The other group (Group 2) 
>>> wants Equatable (and others) be derived explicitly using a `deriving` 
>>> keyword (or something semantically equivalent). Unless I missed something, 
>>> there were no voices for keeping the status quo, and not introducing any 
>>> process to automatically derive these protocols.
>>> 
>>> I think I chose an easy strategy when proposing the `deriving` keyword. 
>>> Haskell is a mature language, and "copying" a feature from them is usually 
>>> a safe choice. For each language feature, someone has to think through all 
>>> the implications of it; this is usually far from trivial. I argue that if I 
>>> take a feature from another language, someone has probably already thought 
>>> about all the pros and cons of different solutions. This is just a plea for 
>>> embracing precedent.
>>> 
>>> There is one advantage of method 2 that (I think) hasn't been discussed so 
>>> far: when you declare a type `S`, and an `Equatable` instance is 
>>> automatically derived, there is no way to override that instance in another 
>>> module. With method 1, there is also no way to request that an `Equatable` 
>>> instance should *not* be generated. I think no one will vote for something 
>>> like `struct S @notderiving(Equateble,Hashable) { ... }`.
>>> 
>>> Also, a `deriving` keyword is less magical than just automatically deriving 
>>> `Equatable` and `Hashable` instances. I think the language rules should be 
>>> as simple as possible, by default. If you want any kind of special 
>>> behavior, you have to ask for it: `deriving Equatable`, `@IBOutlet`, 
>>> `@NSManaged`. Furthermore, I think it is good that the developer is aware 
>>> that there is an "==" method somewhere, specifically for this new type. The 
>>> compiler should not arbitrarily create methods, because someone may need 
>>> them. Even if it is very likely that you will need them. Just like in a 
>>> coffee house, you are asked if you want a coffee, even if you are visiting 
>>> it every day. For example with Objective-C, I want each developer to be 
>>> aware of the difference between a property and an iVar, and be aware of the 
>>> connection between properties, methods, and key-value-coding. The 
>>> complexities of the language shouldn't be hidden completely.
>>> 
>>> Just my two cents..
>>> 
>>> -Michael
>>> 
>>> ___
>>> 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
> 
> ___
> 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

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Patrick Smith via swift-evolution]

Yes exactly, use the protocol conformance syntax, Michael’s description was 
mistaken I think.

Just the same way you get protocol extensions without having to use a special 
keyword.


> On 31 May 2016, at 6:26 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> I see these two groups: both wants explicit conformance to protocols, but 
> first thinks that current syntax is enough (`: Equatable`) and second thinks 
> we should introduce new keyword `deriving` for this(`: deriving Equatable`). 
> I see no opinions(except the one opinion in proposal itself) to automatically 
> deriving without explicit decoration.
> 
> On 30.05.2016 22:04, Michael Peternell via swift-evolution wrote:
>> It seems that there are two groups here. 1) Group 1 wants Equatable (and 
>> others) be derived automatically unless specifically overridden: similar to 
>> auto-synthesis of properties in Objective-C. 2) The other group (Group 2) 
>> wants Equatable (and others) be derived explicitly using a `deriving` 
>> keyword (or something semantically equivalent). Unless I missed something, 
>> there were no voices for keeping the status quo, and not introducing any 
>> process to automatically derive these protocols.
>> 
>> I think I chose an easy strategy when proposing the `deriving` keyword. 
>> Haskell is a mature language, and "copying" a feature from them is usually a 
>> safe choice. For each language feature, someone has to think through all the 
>> implications of it; this is usually far from trivial. I argue that if I take 
>> a feature from another language, someone has probably already thought about 
>> all the pros and cons of different solutions. This is just a plea for 
>> embracing precedent.
>> 
>> There is one advantage of method 2 that (I think) hasn't been discussed so 
>> far: when you declare a type `S`, and an `Equatable` instance is 
>> automatically derived, there is no way to override that instance in another 
>> module. With method 1, there is also no way to request that an `Equatable` 
>> instance should *not* be generated. I think no one will vote for something 
>> like `struct S @notderiving(Equateble,Hashable) { ... }`.
>> 
>> Also, a `deriving` keyword is less magical than just automatically deriving 
>> `Equatable` and `Hashable` instances. I think the language rules should be 
>> as simple as possible, by default. If you want any kind of special behavior, 
>> you have to ask for it: `deriving Equatable`, `@IBOutlet`, `@NSManaged`. 
>> Furthermore, I think it is good that the developer is aware that there is an 
>> "==" method somewhere, specifically for this new type. The compiler should 
>> not arbitrarily create methods, because someone may need them. Even if it is 
>> very likely that you will need them. Just like in a coffee house, you are 
>> asked if you want a coffee, even if you are visiting it every day. For 
>> example with Objective-C, I want each developer to be aware of the 
>> difference between a property and an iVar, and be aware of the connection 
>> between properties, methods, and key-value-coding. The complexities of the 
>> language shouldn't be hidden completely.
>> 
>> Just my two cents..
>> 
>> -Michael
>> 
>> ___
>> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Michael Peternell via swift-evolution]

I'm not a fan of AutoEquatable or AutoHashable. These protocols suggest that 
automatic conformance can be defined in the language itself and that derived 
protocol instances don't have to be implemented as compiler intrinsics. That's 
just not the case. You cannot define something like

@auto protocol AutoEquatable : Equatable {
   ...
}

because what would you write instead of "..."? Copy Lisp-Macros? Copy 
Template-Haskell? I don't really need to disagree here, I could just say "good 
idea, do you want to make a proposal for this?" and then I will never hear 
again anything from this idea, because no one will be able to write the 
"detailed design" section of that proposal. (at least, I don't know how to 
design such a feature; the solution space looks empty to me. there are similar 
issues with "property behaviors" IMHO, but that's another story.)

Second, there is no point in "prohibiting" any protocols from being "derived". 
But deriving will only work for protocols for which someone has implemented a 
deriving algorithm. And that algorithm has to be implemented in the compiler. I 
think `Comparable`, `CustomStringConvertible` would be good candidates for 
deriving too. The whole point of all of this is to reduce boilerplate code that 
is trivial to write, and also error-prone because no one wants to read that 
boring code carefully (e.g. a custom to-string-function for an enum with 30 
cases, that just returns the name of the symbol and that has to be extended 
each time another case is added: `case Foo1: return "Foo1"; case Bla: return 
"Bla"; ...`).

Third, what is the difference between "deep equality" (AutoDeepEquatable) and 
"shallow equality" (AutoShallowEquatable)?

(A tiny bit) sorry for bashing any other opinions... :-/ But, a solution has to 
1) work, 2) be practical, 3) be implementable, 4) have a possible detailed 
design that is not overly baroque, 5) shouldn't have funny edge cases that will 
disturb users as soon as the feature is used widely.

But since this feature is out-of-scope for Swift 3 anyways, we now have plenty 
of time resolving all these issues.. I may try to write a proposal later this 
year, after Swift 3 has been released. Thanks to everyone who participated in 
the discussion.

-Michael

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[David Sweeris via swift-evolution]

If you're asking me, it depends on what gets filled in for "syntax". I see no 
reason to explicitly prohibit classes from participating, though.

- Dave Sweeris

> On May 30, 2016, at 16:12, Vladimir.S  wrote:
> 
> In case we discuss this feature not for just value types but for classes also 
> - will such AutoEquatable allows to implement protocol manually?
> 
> Now we can have:
> 
> func == (lhs: A, rhs: A) -> Bool { return true }
> class A: Hashable { var hashValue: Int { return 100 } }
> class B: A { override var hashValue: Int { return 200 } }
> 
> So, if we'll have
> class A: AutoHashable { }
> or
> class A: deriving Hashable { }
> will we be able to have:
> class B: A { override var hashValue: Int { return 200 } }
> ?
> 
> (The same question was for `deriving` proposal)
> Please note that we probably don't want/have no rights to modify the 
> definition of class A.
> 
> There is no such question for auto-derived Hashable in case of simple 
> conformance as we do now `class A: Hashable`.
> 
>> On 30.05.2016 23:45, David Sweeris wrote:
>> What about declaring the requirements for auto-conformance in a sub-protocol?
>> @auto protocol AutoEquatable : Equatable {
>>//"syntax" for how to conform to Equatable
>> }
>> 
>> struct Foo : AutoEquatable {} //the compiler automatically synthesizes 
>> everything
>> struct Bar : Equatable {} //you manually conform
>> 
>> It would be a compiler error to conform to an `@auto` protocol if the 
>> compiler couldn't apply the provided "syntax" to the conforming type.
>> 
>> (I have no clue what this "syntax" could be, other than some expansion of 
>> generics and/or a macro system)
>> 
>> Anyway, does that help? It satisfies both the "explicit conformance" crowd 
>> and the "no new keywords" (at least at the "call" site) crowd.
>> 
>> - Dave Sweeris
>> 
>>> On May 30, 2016, at 15:26, Vladimir.S via swift-evolution 
>>>  wrote:
>>> 
>>> I see these two groups: both wants explicit conformance to protocols, but 
>>> first thinks that current syntax is enough (`: Equatable`) and second 
>>> thinks we should introduce new keyword `deriving` for this(`: deriving 
>>> Equatable`). I see no opinions(except the one opinion in proposal itself) 
>>> to automatically deriving without explicit decoration.
>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Vladimir.S via swift-evolution]

In case we discuss this feature not for just value types but for classes 
also - will such AutoEquatable allows to implement protocol manually?


Now we can have:

func == (lhs: A, rhs: A) -> Bool { return true }
class A: Hashable { var hashValue: Int { return 100 } }
class B: A { override var hashValue: Int { return 200 } }

So, if we'll have
class A: AutoHashable { }
or
class A: deriving Hashable { }
will we be able to have:
class B: A { override var hashValue: Int { return 200 } }
?

(The same question was for `deriving` proposal)
Please note that we probably don't want/have no rights to modify the 
definition of class A.


There is no such question for auto-derived Hashable in case of simple 
conformance as we do now `class A: Hashable`.


On 30.05.2016 23:45, David Sweeris wrote:

What about declaring the requirements for auto-conformance in a sub-protocol?
@auto protocol AutoEquatable : Equatable {
//"syntax" for how to conform to Equatable
}

struct Foo : AutoEquatable {} //the compiler automatically synthesizes 
everything
struct Bar : Equatable {} //you manually conform

It would be a compiler error to conform to an `@auto` protocol if the compiler couldn't 
apply the provided "syntax" to the conforming type.

(I have no clue what this "syntax" could be, other than some expansion of 
generics and/or a macro system)

Anyway, does that help? It satisfies both the "explicit conformance" crowd and the "no new 
keywords" (at least at the "call" site) crowd.

- Dave Sweeris


On May 30, 2016, at 15:26, Vladimir.S via swift-evolution 
 wrote:

I see these two groups: both wants explicit conformance to protocols, but first 
thinks that current syntax is enough (`: Equatable`) and second thinks we 
should introduce new keyword `deriving` for this(`: deriving Equatable`). I see 
no opinions(except the one opinion in proposal itself) to automatically 
deriving without explicit decoration.



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Callionica (Swift) via swift-evolution]

Is there no one that thinks it's sufficient if users can create a tuple
from a list of properties and reuse tuple equality and hash?

Is there no one that thinks it's sufficient if the system were to supply a
named function for comparing two Any's for equality (with reference
equality semantics for reference types, bit equality for value types) that
users could use in their type's implementations of ==?

Is there no one that thinks the opt-in mechanism should be a call to a
system supplied function, instead of coming up with new keywords or opting
in directly through the protocol?
(Well I know there's at least one person that thinks the opt in mechanism
should be by calling a function)

-- Callionica

On Mon, May 30, 2016 at 12:04 PM, Michael Peternell via swift-evolution <
swift-evolution@swift.org> wrote:

> It seems that there are two groups here. 1) Group 1 wants Equatable (and
> others) be derived automatically unless specifically overridden: similar to
> auto-synthesis of properties in Objective-C. 2) The other group (Group 2)
> wants Equatable (and others) be derived explicitly using a `deriving`
> keyword (or something semantically equivalent). Unless I missed something,
> there were no voices for keeping the status quo, and not introducing any
> process to automatically derive these protocols.
>
> I think I chose an easy strategy when proposing the `deriving` keyword.
> Haskell is a mature language, and "copying" a feature from them is usually
> a safe choice. For each language feature, someone has to think through all
> the implications of it; this is usually far from trivial. I argue that if I
> take a feature from another language, someone has probably already thought
> about all the pros and cons of different solutions. This is just a plea for
> embracing precedent.
>
> There is one advantage of method 2 that (I think) hasn't been discussed so
> far: when you declare a type `S`, and an `Equatable` instance is
> automatically derived, there is no way to override that instance in another
> module. With method 1, there is also no way to request that an `Equatable`
> instance should *not* be generated. I think no one will vote for something
> like `struct S @notderiving(Equateble,Hashable) { ... }`.
>
> Also, a `deriving` keyword is less magical than just automatically
> deriving `Equatable` and `Hashable` instances. I think the language rules
> should be as simple as possible, by default. If you want any kind of
> special behavior, you have to ask for it: `deriving Equatable`,
> `@IBOutlet`, `@NSManaged`. Furthermore, I think it is good that the
> developer is aware that there is an "==" method somewhere, specifically for
> this new type. The compiler should not arbitrarily create methods, because
> someone may need them. Even if it is very likely that you will need them.
> Just like in a coffee house, you are asked if you want a coffee, even if
> you are visiting it every day. For example with Objective-C, I want each
> developer to be aware of the difference between a property and an iVar, and
> be aware of the connection between properties, methods, and
> key-value-coding. The complexities of the language shouldn't be hidden
> completely.
>
> Just my two cents..
>
> -Michael
>
> ___
> 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

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[David Sweeris via swift-evolution]

What about declaring the requirements for auto-conformance in a sub-protocol?
@auto protocol AutoEquatable : Equatable {
//"syntax" for how to conform to Equatable
}

struct Foo : AutoEquatable {} //the compiler automatically synthesizes 
everything
struct Bar : Equatable {} //you manually conform

It would be a compiler error to conform to an `@auto` protocol if the compiler 
couldn't apply the provided "syntax" to the conforming type.

(I have no clue what this "syntax" could be, other than some expansion of 
generics and/or a macro system)

Anyway, does that help? It satisfies both the "explicit conformance" crowd and 
the "no new keywords" (at least at the "call" site) crowd.

- Dave Sweeris

> On May 30, 2016, at 15:26, Vladimir.S via swift-evolution 
>  wrote:
> 
> I see these two groups: both wants explicit conformance to protocols, but 
> first thinks that current syntax is enough (`: Equatable`) and second thinks 
> we should introduce new keyword `deriving` for this(`: deriving Equatable`). 
> I see no opinions(except the one opinion in proposal itself) to automatically 
> deriving without explicit decoration.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Chris Lattner via swift-evolution]

> On May 30, 2016, at 12:04 PM, Michael Peternell via swift-evolution 
>  wrote:
> 
> It seems that there are two groups here. 1) Group 1 wants Equatable (and 
> others) be derived automatically unless specifically overridden: similar to 
> auto-synthesis of properties in Objective-C. 2) The other group (Group 2) 
> wants Equatable (and others) be derived explicitly using a `deriving` keyword 
> (or something semantically equivalent). Unless I missed something, there were 
> no voices for keeping the status quo, and not introducing any process to 
> automatically derive these protocols.

FWIW, I’m pretty firmly in “camp 2” by the definition above.

That said, any work in this area is significantly outside the scope of what we 
can do in Swift 3, so I can’t engage in further discussion until we can get 
past the things that are pressing and critical for this release.  PRs for an 
evolution proposal along these lines won’t be accepted until Swift 3 is winding 
way down, and at that point, we’ll have to have the whole “pitch” discussion 
again.

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Vladimir.S via swift-evolution]

I see these two groups: both wants explicit conformance to protocols, but 
first thinks that current syntax is enough (`: Equatable`) and second 
thinks we should introduce new keyword `deriving` for this(`: deriving 
Equatable`). I see no opinions(except the one opinion in proposal itself) 
to automatically deriving without explicit decoration.


On 30.05.2016 22:04, Michael Peternell via swift-evolution wrote:

It seems that there are two groups here. 1) Group 1 wants Equatable (and 
others) be derived automatically unless specifically overridden: similar to 
auto-synthesis of properties in Objective-C. 2) The other group (Group 2) wants 
Equatable (and others) be derived explicitly using a `deriving` keyword (or 
something semantically equivalent). Unless I missed something, there were no 
voices for keeping the status quo, and not introducing any process to 
automatically derive these protocols.

I think I chose an easy strategy when proposing the `deriving` keyword. Haskell is a 
mature language, and "copying" a feature from them is usually a safe choice. 
For each language feature, someone has to think through all the implications of it; this 
is usually far from trivial. I argue that if I take a feature from another language, 
someone has probably already thought about all the pros and cons of different solutions. 
This is just a plea for embracing precedent.

There is one advantage of method 2 that (I think) hasn't been discussed so far: 
when you declare a type `S`, and an `Equatable` instance is automatically 
derived, there is no way to override that instance in another module. With 
method 1, there is also no way to request that an `Equatable` instance should 
*not* be generated. I think no one will vote for something like `struct S 
@notderiving(Equateble,Hashable) { ... }`.

Also, a `deriving` keyword is less magical than just automatically deriving `Equatable` 
and `Hashable` instances. I think the language rules should be as simple as possible, by 
default. If you want any kind of special behavior, you have to ask for it: `deriving 
Equatable`, `@IBOutlet`, `@NSManaged`. Furthermore, I think it is good that the developer 
is aware that there is an "==" method somewhere, specifically for this new 
type. The compiler should not arbitrarily create methods, because someone may need them. 
Even if it is very likely that you will need them. Just like in a coffee house, you are 
asked if you want a coffee, even if you are visiting it every day. For example with 
Objective-C, I want each developer to be aware of the difference between a property and 
an iVar, and be aware of the connection between properties, methods, and 
key-value-coding. The complexities of the language shouldn't be hidden completely.

Just my two cents..

-Michael

___
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

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[L Mihalkovic via swift-evolution]

Seems to me like a heavy weight solution to invent a special keyword that will 
be applicable to 2 protocols in the entire standard library. 

If I am not mistaken, the Swift philosophy seems to be that Protocols carry the 
meaning, not how we apply them. So in this instance, something like the 
following might convey the meaning of both equality, and how the compiler 
should assist.

public protocol Equatable {
@warn_unused_result
public func ==(lhs: Self, rhs: Self) -> Bool
}


/// Declaring conformance to this protocol results in the compiler
/// automatically generating a deep-equal between each members of
/// the conforming instances
public protocol AutoDeepEquatable : Equatable {
}

/// Declaring conformance to this protocol results in the compiler
/// automatically generating a shallow-equal between each members 
/// of the conforming instances
public protocol AutoShallowEquatable : Equatable {
}




> On May 30, 2016, at 9:04 PM, Michael Peternell via swift-evolution 
>  wrote:
> 
> It seems that there are two groups here. 1) Group 1 wants Equatable (and 
> others) be derived automatically unless specifically overridden: similar to 
> auto-synthesis of properties in Objective-C. 2) The other group (Group 2) 
> wants Equatable (and others) be derived explicitly using a `deriving` keyword 
> (or something semantically equivalent). Unless I missed something, there were 
> no voices for keeping the status quo, and not introducing any process to 
> automatically derive these protocols.
> 
> I think I chose an easy strategy when proposing the `deriving` keyword. 
> Haskell is a mature language, and "copying" a feature from them is usually a 
> safe choice. For each language feature, someone has to think through all the 
> implications of it; this is usually far from trivial. I argue that if I take 
> a feature from another language, someone has probably already thought about 
> all the pros and cons of different solutions. This is just a plea for 
> embracing precedent.
> 
> There is one advantage of method 2 that (I think) hasn't been discussed so 
> far: when you declare a type `S`, and an `Equatable` instance is 
> automatically derived, there is no way to override that instance in another 
> module. With method 1, there is also no way to request that an `Equatable` 
> instance should *not* be generated. I think no one will vote for something 
> like `struct S @notderiving(Equateble,Hashable) { ... }`.
> 
> Also, a `deriving` keyword is less magical than just automatically deriving 
> `Equatable` and `Hashable` instances. I think the language rules should be as 
> simple as possible, by default. If you want any kind of special behavior, you 
> have to ask for it: `deriving Equatable`, `@IBOutlet`, `@NSManaged`. 
> Furthermore, I think it is good that the developer is aware that there is an 
> "==" method somewhere, specifically for this new type. The compiler should 
> not arbitrarily create methods, because someone may need them. Even if it is 
> very likely that you will need them. Just like in a coffee house, you are 
> asked if you want a coffee, even if you are visiting it every day. For 
> example with Objective-C, I want each developer to be aware of the difference 
> between a property and an iVar, and be aware of the connection between 
> properties, methods, and key-value-coding. The complexities of the language 
> shouldn't be hidden completely.
> 
> Just my two cents..
> 
> -Michael
> 
> ___
> 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

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Michael Peternell via swift-evolution]

It seems that there are two groups here. 1) Group 1 wants Equatable (and 
others) be derived automatically unless specifically overridden: similar to 
auto-synthesis of properties in Objective-C. 2) The other group (Group 2) wants 
Equatable (and others) be derived explicitly using a `deriving` keyword (or 
something semantically equivalent). Unless I missed something, there were no 
voices for keeping the status quo, and not introducing any process to 
automatically derive these protocols.

I think I chose an easy strategy when proposing the `deriving` keyword. Haskell 
is a mature language, and "copying" a feature from them is usually a safe 
choice. For each language feature, someone has to think through all the 
implications of it; this is usually far from trivial. I argue that if I take a 
feature from another language, someone has probably already thought about all 
the pros and cons of different solutions. This is just a plea for embracing 
precedent.

There is one advantage of method 2 that (I think) hasn't been discussed so far: 
when you declare a type `S`, and an `Equatable` instance is automatically 
derived, there is no way to override that instance in another module. With 
method 1, there is also no way to request that an `Equatable` instance should 
*not* be generated. I think no one will vote for something like `struct S 
@notderiving(Equateble,Hashable) { ... }`.

Also, a `deriving` keyword is less magical than just automatically deriving 
`Equatable` and `Hashable` instances. I think the language rules should be as 
simple as possible, by default. If you want any kind of special behavior, you 
have to ask for it: `deriving Equatable`, `@IBOutlet`, `@NSManaged`. 
Furthermore, I think it is good that the developer is aware that there is an 
"==" method somewhere, specifically for this new type. The compiler should not 
arbitrarily create methods, because someone may need them. Even if it is very 
likely that you will need them. Just like in a coffee house, you are asked if 
you want a coffee, even if you are visiting it every day. For example with 
Objective-C, I want each developer to be aware of the difference between a 
property and an iVar, and be aware of the connection between properties, 
methods, and key-value-coding. The complexities of the language shouldn't be 
hidden completely.

Just my two cents..

-Michael

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Frank Ecsedy via swift-evolution]

In Java I would use Project Lombok's @EqualsAndHashCode annotation on a
class. Caveats:

1. Swift is not Java and that's a good thing (TM).
2. Project Lombok is not Java, either.
3. 'deriving Equatable, Hashable' makes those interfaces 'magic'. Is that
good?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[L Mihalkovic via swift-evolution]

> On May 29, 2016, at 4:12 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> On 27.05.2016 18:37, plx via swift-evolution wrote:
>> 
>>> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution
>>> > wrote:
>>> 
>>> A `deriving` keyword, at the very least, is pretty explicitly *not* an
>>> all-or-nothing situation. If you want to define equality/hashability for
>>> your type manually, don't use `deriving`. This should leave the simplest
>>> cases to auto generation and anything more complex should be handled by
>>> the developer.
>> 
>> It’s all-or-nothing in the sense you can’t use a naive `deriving`
>> implementation to assist in any case where what you need is *almost* the
>> trivial implementation, but not quite.
> 
> I support that we need a way to exclude some fields from participate in 
> auto-derived code. It is not handy if we'll have just one-two excluded 
> properties (of 10 for example) and we'll need to implement the boilerplate 
> code because of this. Probably, this should be another proposal for this 
> feature.
> 

the fact that other existing systems work that way for years is a good 
indication that it is a REAL need.


> Just some thoughts: such a method to decorate some fields as 
> `nonequatable`/`nonhashable` has no meaning *if* Equatable/Hashable is later 
> implemented manually. So, to remove confusion, it seems like such 'method' to 
> exclude should be disallowed(by compiler) if protocols are implemented 
> manually by coder.
> I.e., I don't want to see a code where we have *both* explicit 
> implementations of protocols *and* some decorators/special functions to 
> exclude some fields as this will no any sense.
> 
> Also for me it seems like we need to be able to define such attribute near 
> the field itself, to prevent later errors when you define new field but 
> forgot to add it to some 'special list' of excluded field somewhere in code.
> So, probably I'd prefer some kind of @nonequatable and @nonhashable :
> @nonequatable var field = 0
> 
> 
>> 
>> Consider a case like this:
>> 
>>  class QuxEvaluator  {
>> 
>>let foo: Foo // Equatable
>>let bar: Bar // Equatable
>>let baz: Baz // Equatable
>> 
>>private var quxCache: [QuxIdentifier:Qux] // [Equatable:Equatable] = [:]
>> 
>>// pure function of `foo`, `bar`, `baz`, and `identifier`
>>// expensive, and uses `quxCache` for memoization
>>func qux(for identifier: QuxIdentifier) -> Qux
>> 
>>  }
>> 
>> …if it weren’t for `quxCache` we could easily synthesize `==` for
>> `QuxEvaluator`, but the trivial synthesis will yield invalid results due to
>> `[QuxIdentifier:Qux]` also being `Equatable` (really: it *will* also be
>> equatable once conditional conformances are in place).
>> 
>> So we’re back to e.g. writing this:
>> 
>>  extension QuxEvaluator : Equatable {
>> 
>>  }
>> 
>>  func ==(lhs: QuxEvaluator, rhs: QuxEvaluator) -> Bool {
>>return (lhs === rhs) || (lhs.foo == rhs.foo && lhs.bar == rhs.bar &&
>> lhs.baz == rhs.baz)
>>  }
>> 
>> …just to omit a single field from the `==` consideration; this is another
>> sense in which you can say deriving is an all-or-none; there’s just no way
>> to invoke the synthesis mechanism other than for "all fields”.
>> 
>> On the one hand, it’s possible to imagine a finer-grained form of this
>> synthesis that’d allow you to e.g. indicate a certain field should be
>> omitted (and also perhaps specialize how fields are compared, customize the
>> synthesized comparison ordering to put cheaper comparisons earlier, and an
>> endless list of other possible requests…).
>> 
>> On the other hand, the memberwise-init proposal had a very similar
>> situation: the naive approach was arguably too narrow, but it proved very
>> difficult to find a workable balance between customization and
>> implementation complexity (leaving it postponed for the foreseeable
>> future); it’d be a pity if synthesis like this fell into the same trap.
>> 
>> But, on the gripping hand, I highly suspect that a naive
>> `deriving`/synthesis will wind up being too narrowly-useful to really
>> justify; that’s just my opinion, of course.
>> 
>>> 
>>> On Thu, May 26, 2016 at 11:20 AM, L. Mihalkovic
>>> > wrote:
>>> 
>>>what i care about is to have a choice about what DEFINES the identity
>>>of my values, not just an all-or-nothing situation.
>>> 
>>>On May 26, 2016, at 5:18 PM, T.J. Usiyan via swift-evolution
>>>> wrote:
>>> 
+1 to a `deriving` keyword
 
On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via
swift-evolution > wrote:
 
Can we just copy the solution from Haskell instead of
creating our own? It's just better in every aspect. 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[L Mihalkovic via swift-evolution]

> On May 29, 2016, at 3:31 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On May 29, 2016, at 8:25 AM, Vladimir.S  wrote:
>> 
>> 
>> Should 'deriving' allows us to manually implement protocol requirements? For 
>> example
>> struct A : deriving Hashable {
>> var hasValue : Int {...}
>> }
>> 
>> Or there should be a compilation error in this case?
> 
> This should be an error.  If you want to implement it manually your should 
> use the usual conformance declaration syntax.

Considering it can all be done without deriving, so I wager they will never add 
it 


> 
>> 
>> Right now I feel that if we can have auto-deriving by using current syntax 
>> for protocol conformance - we sholdn't introduce new keyword and new rules 
>> for this.
> 
> We've already covered the reasons why this is problematic.  It's better to be 
> explicit about the request for synthesized conformance.
> 
>> The requirement to explicitly conform your type to protocol for 
>> auto-deriving is IMO reasonable compromise between separate 'deriving' 
>> decoration and implicit derivation(when your type is Hashable without any 
>> conformance to protocol, just if each property is Hashable).
>> 
>>> On 29.05.2016 14:42, Matthew Johnson via swift-evolution wrote:
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>> On May 29, 2016, at 12:28 AM, Patrick Smith >> > wrote:
>>> 
 Yeah I don’t see a problem. It’s the same way that protocol extensions
 just work. Think of this automatic synthesis as a really flexible
 protocol extension:
 
 extension Hashable where Members : Hashable {
 var hashValue : Int {
   return self.allMembers.reduce(^) // Or whatever combiner is best
 }
 }
>>> 
>>> Protocol extensions require you to declare conformance before your type
>>> receives their implementation and it must be identical for all do
>>> conforming types.
>>> 
>>> You should have to declare conformance to receive Equatable conformance and
>>> synthesis.  IMO it makes sense to do that with 'deriving' which makes it
>>> clear that you are requesting synthesized rather than manual conformance.
>>> 
 
 
> On 29 May 2016, at 1:19 PM, Jon Shier via swift-evolution
> > wrote:
> 
>> The problem with this is that it doesn’t differentiate between
>> synthesized and manual conformance.  You won’t get error messages you
>> otherwise would when you intend to supply manual conformance.  It is
>> also less clear to a reader of the code that the default, compiler
>> synthesized implementation is being generated.
> 
> I don’t think it’s reasonable to force the language down the path where
> developers don’t have to be familiar with its features in order to use
> them correctly. If types in Swift were to automatically gain Equatable
> and Hashable conformances whenever they were used by something that
> required them, that would be a core language feature, like type
> inference, that even junior developers in the language would need to
> know. Yet few (though not none) would insist that all types be manually
> declared, despite otherwise not knowing when our type inference goes
> wrong. It’s just a basic feature of the language that anyone using the
> language should know about, otherwise it can bite them in the ass when
> weird compiler errors start popping up.
> Frankly, IMO, this is an obvious case of 80/20 optimization. In the vast
> majority of cases where my types are trivially equatable, I should just
> be able to declare them as such and gain the compiler-synthesized ==. In
> the cases where that’s not possible, the compiler can emit an error. And
> in the cases where I want a custom == implementation I can provide it.
> Requiring a new keyword and not making this feature as simple as
> possible because the rare developer with a custom type who doesn’t want
> the synthesized == they just said they did by declaring Equatable
> conformance is an unnecessary defaulting to the rare case.
> 
> 
> 
> Jon Shier
> ___
> 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
>>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Patrick Smith via swift-evolution]

Yes, and I’ve been arguing for it being explicit by conforming to the Equatable 
/ Hashable protocol. This would then work the same way as protocol extensions. 
Protocol extension don’t require a special ‘deriving’ keyword, so I don’t 
believe there needs to be one here. Just conforming to the protocols is enough.


> On 29 May 2016, at 9:42 PM, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On May 29, 2016, at 12:28 AM, Patrick Smith  > wrote:
> 
>> Yeah I don’t see a problem. It’s the same way that protocol extensions just 
>> work. Think of this automatic synthesis as a really flexible protocol 
>> extension:
>> 
>> extension Hashable where Members : Hashable {
>>   var hashValue : Int {
>> return self.allMembers.reduce(^) // Or whatever combiner is best
>>   }
>> }
> 
> Protocol extensions require you to declare conformance before your type 
> receives their implementation and it must be identical for all do conforming 
> types.  
> 
> You should have to declare conformance to receive Equatable conformance and 
> synthesis.  IMO it makes sense to do that with 'deriving' which makes it 
> clear that you are requesting synthesized rather than manual conformance.
> 
>> 
>> 
>>> On 29 May 2016, at 1:19 PM, Jon Shier via swift-evolution 
>>> > wrote:
>>> 
 The problem with this is that it doesn’t differentiate between synthesized 
 and manual conformance.  You won’t get error messages you otherwise would 
 when you intend to supply manual conformance.  It is also less clear to a 
 reader of the code that the default, compiler synthesized implementation 
 is being generated.
>>> 
>>> I don’t think it’s reasonable to force the language down the path where 
>>> developers don’t have to be familiar with its features in order to use them 
>>> correctly. If types in Swift were to automatically gain Equatable and 
>>> Hashable conformances whenever they were used by something that required 
>>> them, that would be a core language feature, like type inference, that even 
>>> junior developers in the language would need to know. Yet few (though not 
>>> none) would insist that all types be manually declared, despite otherwise 
>>> not knowing when our type inference goes wrong. It’s just a basic feature 
>>> of the language that anyone using the language should know about, otherwise 
>>> it can bite them in the ass when weird compiler errors start popping up. 
>>> Frankly, IMO, this is an obvious case of 80/20 optimization. In the 
>>> vast majority of cases where my types are trivially equatable, I should 
>>> just be able to declare them as such and gain the compiler-synthesized ==. 
>>> In the cases where that’s not possible, the compiler can emit an error. And 
>>> in the cases where I want a custom == implementation I can provide it. 
>>> Requiring a new keyword and not making this feature as simple as possible 
>>> because the rare developer with a custom type who doesn’t want the 
>>> synthesized == they just said they did by declaring Equatable conformance 
>>> is an unnecessary defaulting to the rare case. 
>>> 
>>> 
>>> 
>>> 
>>> Jon Shier
>>> ___
>>> 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

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[plx via swift-evolution]

> On May 29, 2016, at 9:22 AM, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On May 29, 2016, at 9:12 AM, Vladimir.S via swift-evolution 
>>  wrote:
>> 
>>> On 27.05.2016 18:37, plx via swift-evolution wrote:
>>> 
 On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution
 > wrote:
 
 A `deriving` keyword, at the very least, is pretty explicitly *not* an
 all-or-nothing situation. If you want to define equality/hashability for
 your type manually, don't use `deriving`. This should leave the simplest
 cases to auto generation and anything more complex should be handled by
 the developer.
>>> 
>>> It’s all-or-nothing in the sense you can’t use a naive `deriving`
>>> implementation to assist in any case where what you need is *almost* the
>>> trivial implementation, but not quite.
>> 
>> I support that we need a way to exclude some fields from participate in 
>> auto-derived code. It is not handy if we'll have just one-two excluded 
>> properties (of 10 for example) and we'll need to implement the boilerplate 
>> code because of this. Probably, this should be another proposal for this 
>> feature.
>> 
>> Just some thoughts: such a method to decorate some fields as 
>> `nonequatable`/`nonhashable` has no meaning *if* Equatable/Hashable is later 
>> implemented manually. So, to remove confusion, it seems like such 'method' 
>> to exclude should be disallowed(by compiler) if protocols are implemented 
>> manually by coder.
>> I.e., I don't want to see a code where we have *both* explicit 
>> implementations of protocols *and* some decorators/special functions to 
>> exclude some fields as this will no any sense.
>> 
>> Also for me it seems like we need to be able to define such attribute near 
>> the field itself, to prevent later errors when you define new field but 
>> forgot to add it to some 'special list' of excluded field somewhere in code.
>> So, probably I'd prefer some kind of @nonequatable and @nonhashable :
>> @nonequatable var field = 0
> 
> The same members should be considered by both Equatable and Hashable so there 
> would be no need for two separate annotations.  A more general annotation 
> (maybe "nonessential"?) is what we want.

I strongly disagree; IMHO the members considered for hashing *should* be a 
subset of those considered for equality (and “be the same” is a safe default).

As an example, I find I quite frequently wind up with types effectively like so:

struct ArticleContent {
  let articleID: NSUUID 
  let veryLongFullArticleContent: NSData // potentially huge, possibly slow
}

…for which, at least for the intended uses (and the intended data, etc.), 
hashing `articleID` is enough to get a well-behaved hash, and incorporating 
hashes of the other field(s) doesn’t have any apparent benefit.

> 
>> 
>> 
>>> 
>>> Consider a case like this:
>>> 
>>> class QuxEvaluator  {
>>> 
>>>   let foo: Foo // Equatable
>>>   let bar: Bar // Equatable
>>>   let baz: Baz // Equatable
>>> 
>>>   private var quxCache: [QuxIdentifier:Qux] // [Equatable:Equatable] = [:]
>>> 
>>>   // pure function of `foo`, `bar`, `baz`, and `identifier`
>>>   // expensive, and uses `quxCache` for memoization
>>>   func qux(for identifier: QuxIdentifier) -> Qux
>>> 
>>> }
>>> 
>>> …if it weren’t for `quxCache` we could easily synthesize `==` for
>>> `QuxEvaluator`, but the trivial synthesis will yield invalid results due to
>>> `[QuxIdentifier:Qux]` also being `Equatable` (really: it *will* also be
>>> equatable once conditional conformances are in place).
>>> 
>>> So we’re back to e.g. writing this:
>>> 
>>> extension QuxEvaluator : Equatable {
>>> 
>>> }
>>> 
>>> func ==(lhs: QuxEvaluator, rhs: QuxEvaluator) -> Bool {
>>>   return (lhs === rhs) || (lhs.foo == rhs.foo && lhs.bar == rhs.bar &&
>>> lhs.baz == rhs.baz)
>>> }
>>> 
>>> …just to omit a single field from the `==` consideration; this is another
>>> sense in which you can say deriving is an all-or-none; there’s just no way
>>> to invoke the synthesis mechanism other than for "all fields”.
>>> 
>>> On the one hand, it’s possible to imagine a finer-grained form of this
>>> synthesis that’d allow you to e.g. indicate a certain field should be
>>> omitted (and also perhaps specialize how fields are compared, customize the
>>> synthesized comparison ordering to put cheaper comparisons earlier, and an
>>> endless list of other possible requests…).
>>> 
>>> On the other hand, the memberwise-init proposal had a very similar
>>> situation: the naive approach was arguably too narrow, but it proved very
>>> difficult to find a workable balance between customization and
>>> implementation complexity (leaving it postponed for the foreseeable
>>> future); it’d be a pity if synthesis like this fell into the same trap.
>>> 
>>> But, on the gripping hand, I highly suspect that a naive
>>> `deriving`/synthesis will wind 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 29, 2016, at 9:12 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
>> On 27.05.2016 18:37, plx via swift-evolution wrote:
>> 
>>> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution
>>> > wrote:
>>> 
>>> A `deriving` keyword, at the very least, is pretty explicitly *not* an
>>> all-or-nothing situation. If you want to define equality/hashability for
>>> your type manually, don't use `deriving`. This should leave the simplest
>>> cases to auto generation and anything more complex should be handled by
>>> the developer.
>> 
>> It’s all-or-nothing in the sense you can’t use a naive `deriving`
>> implementation to assist in any case where what you need is *almost* the
>> trivial implementation, but not quite.
> 
> I support that we need a way to exclude some fields from participate in 
> auto-derived code. It is not handy if we'll have just one-two excluded 
> properties (of 10 for example) and we'll need to implement the boilerplate 
> code because of this. Probably, this should be another proposal for this 
> feature.
> 
> Just some thoughts: such a method to decorate some fields as 
> `nonequatable`/`nonhashable` has no meaning *if* Equatable/Hashable is later 
> implemented manually. So, to remove confusion, it seems like such 'method' to 
> exclude should be disallowed(by compiler) if protocols are implemented 
> manually by coder.
> I.e., I don't want to see a code where we have *both* explicit 
> implementations of protocols *and* some decorators/special functions to 
> exclude some fields as this will no any sense.
> 
> Also for me it seems like we need to be able to define such attribute near 
> the field itself, to prevent later errors when you define new field but 
> forgot to add it to some 'special list' of excluded field somewhere in code.
> So, probably I'd prefer some kind of @nonequatable and @nonhashable :
> @nonequatable var field = 0

The same members should be considered by both Equatable and Hashable so there 
would be no need for two separate annotations.  A more general annotation 
(maybe "nonessential"?) is what we want.

> 
> 
>> 
>> Consider a case like this:
>> 
>>  class QuxEvaluator  {
>> 
>>let foo: Foo // Equatable
>>let bar: Bar // Equatable
>>let baz: Baz // Equatable
>> 
>>private var quxCache: [QuxIdentifier:Qux] // [Equatable:Equatable] = [:]
>> 
>>// pure function of `foo`, `bar`, `baz`, and `identifier`
>>// expensive, and uses `quxCache` for memoization
>>func qux(for identifier: QuxIdentifier) -> Qux
>> 
>>  }
>> 
>> …if it weren’t for `quxCache` we could easily synthesize `==` for
>> `QuxEvaluator`, but the trivial synthesis will yield invalid results due to
>> `[QuxIdentifier:Qux]` also being `Equatable` (really: it *will* also be
>> equatable once conditional conformances are in place).
>> 
>> So we’re back to e.g. writing this:
>> 
>>  extension QuxEvaluator : Equatable {
>> 
>>  }
>> 
>>  func ==(lhs: QuxEvaluator, rhs: QuxEvaluator) -> Bool {
>>return (lhs === rhs) || (lhs.foo == rhs.foo && lhs.bar == rhs.bar &&
>> lhs.baz == rhs.baz)
>>  }
>> 
>> …just to omit a single field from the `==` consideration; this is another
>> sense in which you can say deriving is an all-or-none; there’s just no way
>> to invoke the synthesis mechanism other than for "all fields”.
>> 
>> On the one hand, it’s possible to imagine a finer-grained form of this
>> synthesis that’d allow you to e.g. indicate a certain field should be
>> omitted (and also perhaps specialize how fields are compared, customize the
>> synthesized comparison ordering to put cheaper comparisons earlier, and an
>> endless list of other possible requests…).
>> 
>> On the other hand, the memberwise-init proposal had a very similar
>> situation: the naive approach was arguably too narrow, but it proved very
>> difficult to find a workable balance between customization and
>> implementation complexity (leaving it postponed for the foreseeable
>> future); it’d be a pity if synthesis like this fell into the same trap.
>> 
>> But, on the gripping hand, I highly suspect that a naive
>> `deriving`/synthesis will wind up being too narrowly-useful to really
>> justify; that’s just my opinion, of course.
>> 
>>> 
>>> On Thu, May 26, 2016 at 11:20 AM, L. Mihalkovic
>>> > wrote:
>>> 
>>>what i care about is to have a choice about what DEFINES the identity
>>>of my values, not just an all-or-nothing situation.
>>> 
>>>On May 26, 2016, at 5:18 PM, T.J. Usiyan via swift-evolution
>>>> wrote:
>>> 
+1 to a `deriving` keyword
 
On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via
swift-evolution > wrote:
 
Can we just 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 29, 2016, at 8:41 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> Saw `class` in examples and want to clarify.. Are we discussing auto-deriving 
> for *value types only*. Or for classes also?
> As I understand, there could be some additional questions/issues for this 
> feature because of class inheritance. But probably this feature could be 
> discussed for `final` classes also?

Classes usually have reference semantics.  In that case reference identity is 
the appropriate definition of equality.  Other kinds of equivalence tests are 
possible but should not have the name ==.

Immutable classes can have value semantics.  In that case a memberwise equality 
is as likely to be correct as it is for structs.  So it is possible we could 
allow synthesis to be requested for classes, it would just result in an error 
more frequently than with structs.


> 
>> On 27.05.2016 22:41, plx via swift-evolution wrote:
>> 
>>> On May 27, 2016, at 10:48 AM, Matthew Johnson >> > wrote:
>>> 
 
 On May 27, 2016, at 10:37 AM, plx via swift-evolution
 > wrote:
 
 
> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution
> > wrote:
> 
> A `deriving` keyword, at the very least, is pretty explicitly *not* an
> all-or-nothing situation. If you want to define equality/hashability
> for your type manually, don't use `deriving`. This should leave the
> simplest cases to auto generation and anything more complex should be
> handled by the developer.
 
 It’s all-or-nothing in the sense you can’t use a naive `deriving`
 implementation to assist in any case where what you need is *almost* the
 trivial implementation, but not quite.
 
 Consider a case like this:
 
  class QuxEvaluator  {
 
let foo: Foo // Equatable
let bar: Bar // Equatable
let baz: Baz // Equatable
 
private var quxCache: [QuxIdentifier:Qux] // [Equatable:Equatable] = [:]
 
// pure function of `foo`, `bar`, `baz`, and `identifier`
// expensive, and uses `quxCache` for memoization
func qux(for identifier: QuxIdentifier) -> Qux
 
  }
 
 …if it weren’t for `quxCache` we could easily synthesize `==` for
 `QuxEvaluator`, but the trivial synthesis will yield invalid results due
 to `[QuxIdentifier:Qux]` also being `Equatable` (really: it *will* also
 be equatable once conditional conformances are in place).
 
 So we’re back to e.g. writing this:
 
  extension QuxEvaluator : Equatable {
 
  }
 
  func ==(lhs: QuxEvaluator, rhs: QuxEvaluator) -> Bool {
return (lhs === rhs) || (lhs.foo == rhs.foo && lhs.bar == rhs.bar &&
 lhs.baz == rhs.baz)
  }
 
 …just to omit a single field from the `==` consideration; this is
 another sense in which you can say deriving is an all-or-none; there’s
 just no way to invoke the synthesis mechanism other than for "all fields”.
>>> 
>>> I don’t see why this must necessarily be the case.  Annotations such as
>>> you describe below could be taken into account by `deriving`.  `deriving`
>>> is just a way to invoke the synthesis mechanism.
>> 
>> Different people are using it differently I think; I agree with you if it’s
>> just the name of the invocation, but I think at least some people are using
>> it as a shorthand for the “naive” implementation (all fields equatable =>
>> equatable).
>> 
>> That is, I meant "naive deriving” to refer to something like this (quoting
>> Patrick):
>> 
>>> It would fail if not all members were Equatable or Hashable. If it was
>>> automatic, you wouldn’t get any warning or sign at all. If you have to
>>> explicitly conform to the protocols, then your intention is clear, and if
>>> an automatic implementation cannot be made (because not all members were
>>> Equatable or Hashable), then you will get an error that you need to
>>> implement the protocol yourself like you do now (i.e. implement == and
>>> hashValue).
>> 
>> …but I could’ve been clearer!
>> 
>>> 
 
 On the one hand, it’s possible to imagine a finer-grained form of this
 synthesis that’d allow you to e.g. indicate a certain field should be
 omitted (and also perhaps specialize how fields are compared, customize
 the synthesized comparison ordering to put cheaper comparisons earlier,
 and an endless list of other possible requests…).
>>> 
>>> If you don’t trust the compiler to optimize this well and therefore want
>>> control over order of comparisons you should probably just implement it
>>> manually.  As you note below, this is a convenience feature that needs to
>>> strike a fine balance.
>> 
>> I agree, but at the same time i think that scenarios like 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Vladimir.S via swift-evolution]

On 27.05.2016 18:37, plx via swift-evolution wrote:



On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution
> wrote:

A `deriving` keyword, at the very least, is pretty explicitly *not* an
all-or-nothing situation. If you want to define equality/hashability for
your type manually, don't use `deriving`. This should leave the simplest
cases to auto generation and anything more complex should be handled by
the developer.


It’s all-or-nothing in the sense you can’t use a naive `deriving`
implementation to assist in any case where what you need is *almost* the
trivial implementation, but not quite.


I support that we need a way to exclude some fields from participate in 
auto-derived code. It is not handy if we'll have just one-two excluded 
properties (of 10 for example) and we'll need to implement the boilerplate 
code because of this. Probably, this should be another proposal for this 
feature.


Just some thoughts: such a method to decorate some fields as 
`nonequatable`/`nonhashable` has no meaning *if* Equatable/Hashable is 
later implemented manually. So, to remove confusion, it seems like such 
'method' to exclude should be disallowed(by compiler) if protocols are 
implemented manually by coder.
I.e., I don't want to see a code where we have *both* explicit 
implementations of protocols *and* some decorators/special functions to 
exclude some fields as this will no any sense.


Also for me it seems like we need to be able to define such attribute near 
the field itself, to prevent later errors when you define new field but 
forgot to add it to some 'special list' of excluded field somewhere in code.

So, probably I'd prefer some kind of @nonequatable and @nonhashable :
@nonequatable var field = 0




Consider a case like this:

  class QuxEvaluator  {

let foo: Foo // Equatable
let bar: Bar // Equatable
let baz: Baz // Equatable

private var quxCache: [QuxIdentifier:Qux] // [Equatable:Equatable] = [:]

// pure function of `foo`, `bar`, `baz`, and `identifier`
// expensive, and uses `quxCache` for memoization
func qux(for identifier: QuxIdentifier) -> Qux

  }

…if it weren’t for `quxCache` we could easily synthesize `==` for
`QuxEvaluator`, but the trivial synthesis will yield invalid results due to
`[QuxIdentifier:Qux]` also being `Equatable` (really: it *will* also be
equatable once conditional conformances are in place).

So we’re back to e.g. writing this:

  extension QuxEvaluator : Equatable {

  }

  func ==(lhs: QuxEvaluator, rhs: QuxEvaluator) -> Bool {
return (lhs === rhs) || (lhs.foo == rhs.foo && lhs.bar == rhs.bar &&
lhs.baz == rhs.baz)
  }

…just to omit a single field from the `==` consideration; this is another
sense in which you can say deriving is an all-or-none; there’s just no way
to invoke the synthesis mechanism other than for "all fields”.

On the one hand, it’s possible to imagine a finer-grained form of this
synthesis that’d allow you to e.g. indicate a certain field should be
omitted (and also perhaps specialize how fields are compared, customize the
synthesized comparison ordering to put cheaper comparisons earlier, and an
endless list of other possible requests…).

On the other hand, the memberwise-init proposal had a very similar
situation: the naive approach was arguably too narrow, but it proved very
difficult to find a workable balance between customization and
implementation complexity (leaving it postponed for the foreseeable
future); it’d be a pity if synthesis like this fell into the same trap.

But, on the gripping hand, I highly suspect that a naive
`deriving`/synthesis will wind up being too narrowly-useful to really
justify; that’s just my opinion, of course.



On Thu, May 26, 2016 at 11:20 AM, L. Mihalkovic
> wrote:

what i care about is to have a choice about what DEFINES the identity
of my values, not just an all-or-nothing situation.

On May 26, 2016, at 5:18 PM, T.J. Usiyan via swift-evolution
> wrote:


+1 to a `deriving` keyword

On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via
swift-evolution > wrote:

Can we just copy the solution from Haskell instead of
creating our own? It's just better in every aspect. Deriving
`Equatable` and `Hashable` would become

struct Polygon deriving Equatable, Hashable {
...
}

This has several advantages:
- you don't have to guess wether `Equatable` or `Hashable`
should be automatically derived or not.
- Deriving becomes an explicit choice.
- If you need a custom `Equatable` implementation (for whatever
reason), you can still do it.
- It doesn't break any code that is unaware of the change

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Vladimir.S via swift-evolution]

Saw `class` in examples and want to clarify.. Are we discussing 
auto-deriving for *value types only*. Or for classes also?
As I understand, there could be some additional questions/issues for this 
feature because of class inheritance. But probably this feature could be 
discussed for `final` classes also?


On 27.05.2016 22:41, plx via swift-evolution wrote:



On May 27, 2016, at 10:48 AM, Matthew Johnson > wrote:



On May 27, 2016, at 10:37 AM, plx via swift-evolution
> wrote:



On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution
> wrote:

A `deriving` keyword, at the very least, is pretty explicitly *not* an
all-or-nothing situation. If you want to define equality/hashability
for your type manually, don't use `deriving`. This should leave the
simplest cases to auto generation and anything more complex should be
handled by the developer.


It’s all-or-nothing in the sense you can’t use a naive `deriving`
implementation to assist in any case where what you need is *almost* the
trivial implementation, but not quite.

Consider a case like this:

  class QuxEvaluator  {

let foo: Foo // Equatable
let bar: Bar // Equatable
let baz: Baz // Equatable

private var quxCache: [QuxIdentifier:Qux] // [Equatable:Equatable] = [:]

// pure function of `foo`, `bar`, `baz`, and `identifier`
// expensive, and uses `quxCache` for memoization
func qux(for identifier: QuxIdentifier) -> Qux

  }

…if it weren’t for `quxCache` we could easily synthesize `==` for
`QuxEvaluator`, but the trivial synthesis will yield invalid results due
to `[QuxIdentifier:Qux]` also being `Equatable` (really: it *will* also
be equatable once conditional conformances are in place).

So we’re back to e.g. writing this:

  extension QuxEvaluator : Equatable {

  }

  func ==(lhs: QuxEvaluator, rhs: QuxEvaluator) -> Bool {
return (lhs === rhs) || (lhs.foo == rhs.foo && lhs.bar == rhs.bar &&
lhs.baz == rhs.baz)
  }

…just to omit a single field from the `==` consideration; this is
another sense in which you can say deriving is an all-or-none; there’s
just no way to invoke the synthesis mechanism other than for "all fields”.


I don’t see why this must necessarily be the case.  Annotations such as
you describe below could be taken into account by `deriving`.  `deriving`
is just a way to invoke the synthesis mechanism.


Different people are using it differently I think; I agree with you if it’s
just the name of the invocation, but I think at least some people are using
it as a shorthand for the “naive” implementation (all fields equatable =>
equatable).

That is, I meant "naive deriving” to refer to something like this (quoting
Patrick):


It would fail if not all members were Equatable or Hashable. If it was
automatic, you wouldn’t get any warning or sign at all. If you have to
explicitly conform to the protocols, then your intention is clear, and if
an automatic implementation cannot be made (because not all members were
Equatable or Hashable), then you will get an error that you need to
implement the protocol yourself like you do now (i.e. implement == and
hashValue).


…but I could’ve been clearer!





On the one hand, it’s possible to imagine a finer-grained form of this
synthesis that’d allow you to e.g. indicate a certain field should be
omitted (and also perhaps specialize how fields are compared, customize
the synthesized comparison ordering to put cheaper comparisons earlier,
and an endless list of other possible requests…).


If you don’t trust the compiler to optimize this well and therefore want
control over order of comparisons you should probably just implement it
manually.  As you note below, this is a convenience feature that needs to
strike a fine balance.


I agree, but at the same time i think that scenarios like this:

  struct RevisionInfo {
let contentID: NSUUID
let revisionID: NSUUID
let contentData: NSData
  }

…aren’t going to be all that uncommon in practice; I think a good “layered”
implementation of the derivation/synthesis logic would suffice (e.g. we
wouldn't *need* special-case handling for ordering, potentially…).



IMO there are two issues involved:

1. How do we invoke the automatic synthesis.
2. How do we have some degree of control over the synthesis that happens.

`deriving` addresses issue 1 and says nothing about issue 2.


Agreed here; 2 is the interesting question. If you look at my initial
response in this thread I tried to suggest a “layered” approach:

Layer A: have some way of directly invoking the synthesis mechanism itself
(e.g. as a special-purpose macro-like construct); it should be powerful
enough to make `==` easy to write, but have some flexibility (implemented
or planned-for-future).

Layer B: add a way to synthesize `==` (etc.) via the construct from Layer A.

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 29, 2016, at 8:25 AM, Vladimir.S  wrote:
> 
> 
> Should 'deriving' allows us to manually implement protocol requirements? For 
> example
> struct A : deriving Hashable {
>  var hasValue : Int {...}
> }
> 
> Or there should be a compilation error in this case?

This should be an error.  If you want to implement it manually your should use 
the usual conformance declaration syntax.

> 
> Right now I feel that if we can have auto-deriving by using current syntax 
> for protocol conformance - we sholdn't introduce new keyword and new rules 
> for this.

We've already covered the reasons why this is problematic.  It's better to be 
explicit about the request for synthesized conformance.

> The requirement to explicitly conform your type to protocol for auto-deriving 
> is IMO reasonable compromise between separate 'deriving' decoration and 
> implicit derivation(when your type is Hashable without any conformance to 
> protocol, just if each property is Hashable).
> 
>> On 29.05.2016 14:42, Matthew Johnson via swift-evolution wrote:
>> 
>> 
>> Sent from my iPad
>> 
>> On May 29, 2016, at 12:28 AM, Patrick Smith > > wrote:
>> 
>>> Yeah I don’t see a problem. It’s the same way that protocol extensions
>>> just work. Think of this automatic synthesis as a really flexible
>>> protocol extension:
>>> 
>>> extension Hashable where Members : Hashable {
>>>  var hashValue : Int {
>>>return self.allMembers.reduce(^) // Or whatever combiner is best
>>>  }
>>> }
>> 
>> Protocol extensions require you to declare conformance before your type
>> receives their implementation and it must be identical for all do
>> conforming types.
>> 
>> You should have to declare conformance to receive Equatable conformance and
>> synthesis.  IMO it makes sense to do that with 'deriving' which makes it
>> clear that you are requesting synthesized rather than manual conformance.
>> 
>>> 
>>> 
 On 29 May 2016, at 1:19 PM, Jon Shier via swift-evolution
 > wrote:
 
> The problem with this is that it doesn’t differentiate between
> synthesized and manual conformance.  You won’t get error messages you
> otherwise would when you intend to supply manual conformance.  It is
> also less clear to a reader of the code that the default, compiler
> synthesized implementation is being generated.
 
 I don’t think it’s reasonable to force the language down the path where
 developers don’t have to be familiar with its features in order to use
 them correctly. If types in Swift were to automatically gain Equatable
 and Hashable conformances whenever they were used by something that
 required them, that would be a core language feature, like type
 inference, that even junior developers in the language would need to
 know. Yet few (though not none) would insist that all types be manually
 declared, despite otherwise not knowing when our type inference goes
 wrong. It’s just a basic feature of the language that anyone using the
 language should know about, otherwise it can bite them in the ass when
 weird compiler errors start popping up.
 Frankly, IMO, this is an obvious case of 80/20 optimization. In the vast
 majority of cases where my types are trivially equatable, I should just
 be able to declare them as such and gain the compiler-synthesized ==. In
 the cases where that’s not possible, the compiler can emit an error. And
 in the cases where I want a custom == implementation I can provide it.
 Requiring a new keyword and not making this feature as simple as
 possible because the rare developer with a custom type who doesn’t want
 the synthesized == they just said they did by declaring Equatable
 conformance is an unnecessary defaulting to the rare case.
 
 
 
 Jon Shier
 ___
 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
>> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Vladimir.S via swift-evolution]

Should 'deriving' allows us to manually implement protocol requirements? 
For example

struct A : deriving Hashable {
  var hasValue : Int {...}
}

Or there should be a compilation error in this case?

Right now I feel that if we can have auto-deriving by using current syntax 
for protocol conformance - we sholdn't introduce new keyword and new rules 
for this.
The requirement to explicitly conform your type to protocol for 
auto-deriving is IMO reasonable compromise between separate 'deriving' 
decoration and implicit derivation(when your type is Hashable without any 
conformance to protocol, just if each property is Hashable).


On 29.05.2016 14:42, Matthew Johnson via swift-evolution wrote:



Sent from my iPad

On May 29, 2016, at 12:28 AM, Patrick Smith > wrote:


Yeah I don’t see a problem. It’s the same way that protocol extensions
just work. Think of this automatic synthesis as a really flexible
protocol extension:

extension Hashable where Members : Hashable {
  var hashValue : Int {
return self.allMembers.reduce(^) // Or whatever combiner is best
  }
}


Protocol extensions require you to declare conformance before your type
receives their implementation and it must be identical for all do
conforming types.

You should have to declare conformance to receive Equatable conformance and
synthesis.  IMO it makes sense to do that with 'deriving' which makes it
clear that you are requesting synthesized rather than manual conformance.





On 29 May 2016, at 1:19 PM, Jon Shier via swift-evolution
> wrote:


The problem with this is that it doesn’t differentiate between
synthesized and manual conformance.  You won’t get error messages you
otherwise would when you intend to supply manual conformance.  It is
also less clear to a reader of the code that the default, compiler
synthesized implementation is being generated.


I don’t think it’s reasonable to force the language down the path where
developers don’t have to be familiar with its features in order to use
them correctly. If types in Swift were to automatically gain Equatable
and Hashable conformances whenever they were used by something that
required them, that would be a core language feature, like type
inference, that even junior developers in the language would need to
know. Yet few (though not none) would insist that all types be manually
declared, despite otherwise not knowing when our type inference goes
wrong. It’s just a basic feature of the language that anyone using the
language should know about, otherwise it can bite them in the ass when
weird compiler errors start popping up.
Frankly, IMO, this is an obvious case of 80/20 optimization. In the vast
majority of cases where my types are trivially equatable, I should just
be able to declare them as such and gain the compiler-synthesized ==. In
the cases where that’s not possible, the compiler can emit an error. And
in the cases where I want a custom == implementation I can provide it.
Requiring a new keyword and not making this feature as simple as
possible because the rare developer with a custom type who doesn’t want
the synthesized == they just said they did by declaring Equatable
conformance is an unnecessary defaulting to the rare case.



Jon Shier
___
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


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 29, 2016, at 12:28 AM, Patrick Smith  wrote:
> 
> Yeah I don’t see a problem. It’s the same way that protocol extensions just 
> work. Think of this automatic synthesis as a really flexible protocol 
> extension:
> 
> extension Hashable where Members : Hashable {
>   var hashValue : Int {
> return self.allMembers.reduce(^) // Or whatever combiner is best
>   }
> }

Protocol extensions require you to declare conformance before your type 
receives their implementation and it must be identical for all do conforming 
types.  

You should have to declare conformance to receive Equatable conformance and 
synthesis.  IMO it makes sense to do that with 'deriving' which makes it clear 
that you are requesting synthesized rather than manual conformance.

> 
> 
>>> On 29 May 2016, at 1:19 PM, Jon Shier via swift-evolution 
>>>  wrote:
>>> 
>>> The problem with this is that it doesn’t differentiate between synthesized 
>>> and manual conformance.  You won’t get error messages you otherwise would 
>>> when you intend to supply manual conformance.  It is also less clear to a 
>>> reader of the code that the default, compiler synthesized implementation is 
>>> being generated.
>> 
>>  I don’t think it’s reasonable to force the language down the path where 
>> developers don’t have to be familiar with its features in order to use them 
>> correctly. If types in Swift were to automatically gain Equatable and 
>> Hashable conformances whenever they were used by something that required 
>> them, that would be a core language feature, like type inference, that even 
>> junior developers in the language would need to know. Yet few (though not 
>> none) would insist that all types be manually declared, despite otherwise 
>> not knowing when our type inference goes wrong. It’s just a basic feature of 
>> the language that anyone using the language should know about, otherwise it 
>> can bite them in the ass when weird compiler errors start popping up. 
>>  Frankly, IMO, this is an obvious case of 80/20 optimization. In the 
>> vast majority of cases where my types are trivially equatable, I should just 
>> be able to declare them as such and gain the compiler-synthesized ==. In the 
>> cases where that’s not possible, the compiler can emit an error. And in the 
>> cases where I want a custom == implementation I can provide it. Requiring a 
>> new keyword and not making this feature as simple as possible because the 
>> rare developer with a custom type who doesn’t want the synthesized == they 
>> just said they did by declaring Equatable conformance is an unnecessary 
>> defaulting to the rare case. 
>>  
>> 
>> 
>> 
>> Jon Shier
>> ___
>> 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

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Jon Shier via swift-evolution]

I’m sorry, I was misusing the 80/20 principle there, not making an 
argument that 80% of all types are trivially Equatable (though I would assert 
the number types that are trivially Equatable would be far greater than those 
that are not). I was merely stating that the rare cases in which a synthesized 
Equatable implementation might not be desired, even if possible, should not 
prevent this feature from existing and being as simple as possible. That is, 
some simple struct that contains only a few stored properties should be 
prevented from having a synthesized Equatable implementation because some 
representation of rational numbers may not be. Nor should I or the language 
have to use some special syntax or keyword to trigger such generation.


Jon Shier

> On May 29, 2016, at 1:23 AM, Xiaodi Wu  wrote:
> 
> That's quite the assertion you make. What's your evidence that 80% of the 
> time an Equatable type is 'trivially' equatable? In stdlib? Foundation?
> 
> If you could demonstrate that it's really the case, I'd probably be inclined 
> to support default synthesis of conformance to Equatable.
> On Sat, May 28, 2016 at 23:19 Jon Shier via swift-evolution 
> > wrote:
>> The problem with this is that it doesn’t differentiate between synthesized 
>> and manual conformance.  You won’t get error messages you otherwise would 
>> when you intend to supply manual conformance.  It is also less clear to a 
>> reader of the code that the default, compiler synthesized implementation is 
>> being generated.
> 
>   I don’t think it’s reasonable to force the language down the path where 
> developers don’t have to be familiar with its features in order to use them 
> correctly. If types in Swift were to automatically gain Equatable and 
> Hashable conformances whenever they were used by something that required 
> them, that would be a core language feature, like type inference, that even 
> junior developers in the language would need to know. Yet few (though not 
> none) would insist that all types be manually declared, despite otherwise not 
> knowing when our type inference goes wrong. It’s just a basic feature of the 
> language that anyone using the language should know about, otherwise it can 
> bite them in the ass when weird compiler errors start popping up. 
>   Frankly, IMO, this is an obvious case of 80/20 optimization. In the 
> vast majority of cases where my types are trivially equatable, I should just 
> be able to declare them as such and gain the compiler-synthesized ==. In the 
> cases where that’s not possible, the compiler can emit an error. And in the 
> cases where I want a custom == implementation I can provide it. Requiring a 
> new keyword and not making this feature as simple as possible because the 
> rare developer with a custom type who doesn’t want the synthesized == they 
> just said they did by declaring Equatable conformance is an unnecessary 
> defaulting to the rare case. 
>   
> 
> 
> 
> Jon Shier
> ___
> 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

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Patrick Smith via swift-evolution]

Yeah I don’t see a problem. It’s the same way that protocol extensions just 
work. Think of this automatic synthesis as a really flexible protocol extension:

extension Hashable where Members : Hashable {
  var hashValue : Int {
return self.allMembers.reduce(^) // Or whatever combiner is best
  }
}


> On 29 May 2016, at 1:19 PM, Jon Shier via swift-evolution 
>  wrote:
> 
>> The problem with this is that it doesn’t differentiate between synthesized 
>> and manual conformance.  You won’t get error messages you otherwise would 
>> when you intend to supply manual conformance.  It is also less clear to a 
>> reader of the code that the default, compiler synthesized implementation is 
>> being generated.
> 
>   I don’t think it’s reasonable to force the language down the path where 
> developers don’t have to be familiar with its features in order to use them 
> correctly. If types in Swift were to automatically gain Equatable and 
> Hashable conformances whenever they were used by something that required 
> them, that would be a core language feature, like type inference, that even 
> junior developers in the language would need to know. Yet few (though not 
> none) would insist that all types be manually declared, despite otherwise not 
> knowing when our type inference goes wrong. It’s just a basic feature of the 
> language that anyone using the language should know about, otherwise it can 
> bite them in the ass when weird compiler errors start popping up. 
>   Frankly, IMO, this is an obvious case of 80/20 optimization. In the 
> vast majority of cases where my types are trivially equatable, I should just 
> be able to declare them as such and gain the compiler-synthesized ==. In the 
> cases where that’s not possible, the compiler can emit an error. And in the 
> cases where I want a custom == implementation I can provide it. Requiring a 
> new keyword and not making this feature as simple as possible because the 
> rare developer with a custom type who doesn’t want the synthesized == they 
> just said they did by declaring Equatable conformance is an unnecessary 
> defaulting to the rare case. 
>   
> 
> 
> 
> Jon Shier
> ___
> 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

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Xiaodi Wu via swift-evolution]

That's quite the assertion you make. What's your evidence that 80% of the
time an Equatable type is 'trivially' equatable? In stdlib? Foundation?

If you could demonstrate that it's really the case, I'd probably be
inclined to support default synthesis of conformance to Equatable.
On Sat, May 28, 2016 at 23:19 Jon Shier via swift-evolution <
swift-evolution@swift.org> wrote:

> The problem with this is that it doesn’t differentiate between synthesized
> and manual conformance.  You won’t get error messages you otherwise would
> when you intend to supply manual conformance.  It is also less clear to a
> reader of the code that the default, compiler synthesized implementation is
> being generated.
>
>
> I don’t think it’s reasonable to force the language down the path where
> developers don’t have to be familiar with its features in order to use them
> correctly. If types in Swift were to automatically gain Equatable and
> Hashable conformances whenever they were used by something that required
> them, that would be a core language feature, like type inference, that even
> junior developers in the language would need to know. Yet few (though not
> none) would insist that all types be manually declared, despite otherwise
> not knowing when our type inference goes wrong. It’s just a basic feature
> of the language that anyone using the language should know about, otherwise
> it can bite them in the ass when weird compiler errors start popping up.
> Frankly, IMO, this is an obvious case of 80/20 optimization. In the vast
> majority of cases where my types are trivially equatable, I should just be
> able to declare them as such and gain the compiler-synthesized ==. In the
> cases where that’s not possible, the compiler can emit an error. And in the
> cases where I want a custom == implementation I can provide it. Requiring a
> new keyword and not making this feature as simple as possible because the
> rare developer with a custom type who doesn’t want the synthesized == they
> just said they did by declaring Equatable conformance is an unnecessary
> defaulting to the rare case.
>
>
>
> Jon Shier
> ___
> 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

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Jon Shier via swift-evolution]

> The problem with this is that it doesn’t differentiate between synthesized 
> and manual conformance.  You won’t get error messages you otherwise would 
> when you intend to supply manual conformance.  It is also less clear to a 
> reader of the code that the default, compiler synthesized implementation is 
> being generated.

I don’t think it’s reasonable to force the language down the path where 
developers don’t have to be familiar with its features in order to use them 
correctly. If types in Swift were to automatically gain Equatable and Hashable 
conformances whenever they were used by something that required them, that 
would be a core language feature, like type inference, that even junior 
developers in the language would need to know. Yet few (though not none) would 
insist that all types be manually declared, despite otherwise not knowing when 
our type inference goes wrong. It’s just a basic feature of the language that 
anyone using the language should know about, otherwise it can bite them in the 
ass when weird compiler errors start popping up. 
Frankly, IMO, this is an obvious case of 80/20 optimization. In the 
vast majority of cases where my types are trivially equatable, I should just be 
able to declare them as such and gain the compiler-synthesized ==. In the cases 
where that’s not possible, the compiler can emit an error. And in the cases 
where I want a custom == implementation I can provide it. Requiring a new 
keyword and not making this feature as simple as possible because the rare 
developer with a custom type who doesn’t want the synthesized == they just said 
they did by declaring Equatable conformance is an unnecessary defaulting to the 
rare case. 




Jon Shier___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Matthew Johnson via swift-evolution]

> On May 28, 2016, at 8:43 PM, Pedro Vieira via swift-evolution 
>  wrote:
> 
> I really think this would be a great addition to Swift. Although, I don't see 
> the need to use a new keyword `deriving` for this feature.
> The following would be enough:
> 
> struct Foo: Equatable, Hashable {
>   ...
> }
> 
> It's explicit and it uses features already in the language. With this, the 
> compiler would generate all the functions needed for `Foo` to conform to 
> `Equatable` and `Hashable` and, in case the developer wants custom behavior 
> on any of those functions, he/she could just write it from scratch and the 
> compiler would use it over the generated one.

The problem with this is that it doesn’t differentiate between synthesized and 
manual conformance.  You won’t get error messages you otherwise would when you 
intend to supply manual conformance.  It is also less clear to a reader of the 
code that the default, compiler synthesized implementation is being generated.

> 
> Michael Peternell via swift-evolution  > escreveu no dia quinta, 26/05/2016 às 
> 10:58:
> Can we just copy the solution from Haskell instead of creating our own? 
> It's just better in every aspect. Deriving `Equatable` and `Hashable` would 
> become
> 
> struct Polygon deriving Equatable, Hashable {
> ...
> }
> 
> This has several advantages:
> - you don't have to guess wether `Equatable` or `Hashable` should be 
> automatically derived or not.
> - Deriving becomes an explicit choice.
> - If you need a custom `Equatable` implementation (for whatever reason), you 
> can still do it.
> - It doesn't break any code that is unaware of the change
> - It can be extended in future versions of Swift, without introducing any new 
> incompatibilities. For example, `CustomStringConvertible` could be derived 
> just as easily.
> - It is compatible with generics. E.g. `struct Shape deriving Equatable` 
> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
> equatable, `Shape` can be used as well. (Unless `X` is not used, in which 
> case every `Shape` would be equatable. Unless something in the definition 
> of `Shape` makes deriving `Equatable` impossible => this produces an error.)
> - It is proven to work in production.
> 
> -Michael
> 
> Pedro Vieira
> http://pedrovieira.me 
> -- 
> Pedro Vieira
> http://pedrovieira.me 
> ___
> 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

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 27, 2016, at 10:08 PM, Patrick Smith via swift-evolution 
>  wrote:
> 
> A different way of layering could be allowing value types to be composed, 
> where the outer type inherits the inner member’s properties and methods.
> 
> Let’s say you want only fields ‘contentID’ and ‘contentData' to participate 
> in equality and hashing, but not ‘revisionID':
> 
>   struct ContentInfo : Equatable, Hashable { // Automatic implementations for 
> == and hashValue are provided since members conform
> let contentID: NSUUID
> let contentData: NSData
>   }
> 
>   struct RevisionInfo : Equatable, Hashable {
> let revisionID: NSUUID
> private let content: ContentInfo // Hidden from the outside world
> public compose content // Adds .contentID, .contentData, .hashValue 
> properties to RevisionInfo that delegate to those of `content`
>   }
> 
>   func ==(lhs: RevisionInfo, rhs: RevisionInfo) -> Bool {
> return lhs.content == rhs.content
>   }

This is pretty similar to embedding in Go.  It is an interesting feature but I 
don't think it's that relevant to compiler synthesized Equatable and Hashable. 

> 
> 
>>> On 28 May 2016, at 5:41 AM, plx via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On May 27, 2016, at 10:48 AM, Matthew Johnson  
 wrote:
 
 
> On May 27, 2016, at 10:37 AM, plx via swift-evolution 
>  wrote:
> 
> 
 
> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> A `deriving` keyword, at the very least, is pretty explicitly *not* an 
> all-or-nothing situation. If you want to define equality/hashability for 
> your type manually, don't use `deriving`. This should leave the simplest 
> cases to auto generation and anything more complex should be handled by 
> the developer.
 
 It’s all-or-nothing in the sense you can’t use a naive `deriving` 
 implementation to assist in any case where what you need is *almost* the 
 trivial implementation, but not quite.
 
 Consider a case like this:
 
   class QuxEvaluator  {
   
 let foo: Foo // Equatable
 let bar: Bar // Equatable
 let baz: Baz // Equatable
 
 private var quxCache: [QuxIdentifier:Qux] // [Equatable:Equatable] = 
 [:]
 
 // pure function of `foo`, `bar`, `baz`, and `identifier`
 // expensive, and uses `quxCache` for memoization 
 func qux(for identifier: QuxIdentifier) -> Qux
 
   }
 
 …if it weren’t for `quxCache` we could easily synthesize `==` for 
 `QuxEvaluator`, but the trivial synthesis will yield invalid results due 
 to `[QuxIdentifier:Qux]` also being `Equatable` (really: it *will* also be 
 equatable once conditional conformances are in place).
 
 So we’re back to e.g. writing this: 
 
   extension QuxEvaluator : Equatable {
 
   }
 
   func ==(lhs: QuxEvaluator, rhs: QuxEvaluator) -> Bool {
 return (lhs === rhs) || (lhs.foo == rhs.foo && lhs.bar == rhs.bar && 
 lhs.baz == rhs.baz)
   }
 
 …just to omit a single field from the `==` consideration; this is another 
 sense in which you can say deriving is an all-or-none; there’s just no way 
 to invoke the synthesis mechanism other than for "all fields”.
>>> 
>>> I don’t see why this must necessarily be the case.  Annotations such as you 
>>> describe below could be taken into account by `deriving`.  `deriving` is 
>>> just a way to invoke the synthesis mechanism.
>> 
>> Different people are using it differently I think; I agree with you if it’s 
>> just the name of the invocation, but I think at least some people are using 
>> it as a shorthand for the “naive” implementation (all fields equatable => 
>> equatable).
>> 
>> That is, I meant "naive deriving” to refer to something like this (quoting 
>> Patrick):
>> 
>>> It would fail if not all members were Equatable or Hashable. If it was 
>>> automatic, you wouldn’t get any warning or sign at all. If you have to 
>>> explicitly conform to the protocols, then your intention is clear, and if 
>>> an automatic implementation cannot be made (because not all members were 
>>> Equatable or Hashable), then you will get an error that you need to 
>>> implement the protocol yourself like you do now (i.e. implement == and 
>>> hashValue).
>> 
>> 
>> …but I could’ve been clearer!
>> 
>>> 
 
 On the one hand, it’s possible to imagine a finer-grained form of this 
 synthesis that’d allow you to e.g. indicate a certain field should be 
 omitted (and also perhaps specialize how fields are compared, customize 
 the synthesized comparison ordering to put cheaper comparisons earlier, 
 and an endless list of other possible requests…).
>>> 
>>> If you don’t trust the compiler to 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Patrick Smith via swift-evolution]

A different way of layering could be allowing value types to be composed, where 
the outer type inherits the inner member’s properties and methods.

Let’s say you want only fields ‘contentID’ and ‘contentData' to participate in 
equality and hashing, but not ‘revisionID':

  struct ContentInfo : Equatable, Hashable { // Automatic implementations for 
== and hashValue are provided since members conform
let contentID: NSUUID
let contentData: NSData
  }

  struct RevisionInfo : Equatable, Hashable {
let revisionID: NSUUID
private let content: ContentInfo // Hidden from the outside world
public compose content // Adds .contentID, .contentData, .hashValue 
properties to RevisionInfo that delegate to those of `content`
  }

  func ==(lhs: RevisionInfo, rhs: RevisionInfo) -> Bool {
return lhs.content == rhs.content
  }


> On 28 May 2016, at 5:41 AM, plx via swift-evolution 
>  wrote:
> 
>> 
>> On May 27, 2016, at 10:48 AM, Matthew Johnson > > wrote:
>> 
>>> 
>>> On May 27, 2016, at 10:37 AM, plx via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution 
 > wrote:
 
 A `deriving` keyword, at the very least, is pretty explicitly *not* an 
 all-or-nothing situation. If you want to define equality/hashability for 
 your type manually, don't use `deriving`. This should leave the simplest 
 cases to auto generation and anything more complex should be handled by 
 the developer.
>>> 
>>> It’s all-or-nothing in the sense you can’t use a naive `deriving` 
>>> implementation to assist in any case where what you need is *almost* the 
>>> trivial implementation, but not quite.
>>> 
>>> Consider a case like this:
>>> 
>>>   class QuxEvaluator  {
>>>   
>>> let foo: Foo // Equatable
>>> let bar: Bar // Equatable
>>> let baz: Baz // Equatable
>>> 
>>> private var quxCache: [QuxIdentifier:Qux] // [Equatable:Equatable] = [:]
>>> 
>>> // pure function of `foo`, `bar`, `baz`, and `identifier`
>>> // expensive, and uses `quxCache` for memoization 
>>> func qux(for identifier: QuxIdentifier) -> Qux
>>> 
>>>   }
>>> 
>>> …if it weren’t for `quxCache` we could easily synthesize `==` for 
>>> `QuxEvaluator`, but the trivial synthesis will yield invalid results due to 
>>> `[QuxIdentifier:Qux]` also being `Equatable` (really: it *will* also be 
>>> equatable once conditional conformances are in place).
>>> 
>>> So we’re back to e.g. writing this: 
>>> 
>>>   extension QuxEvaluator : Equatable {
>>> 
>>>   }
>>> 
>>>   func ==(lhs: QuxEvaluator, rhs: QuxEvaluator) -> Bool {
>>> return (lhs === rhs) || (lhs.foo == rhs.foo && lhs.bar == rhs.bar && 
>>> lhs.baz == rhs.baz)
>>>   }
>>> 
>>> …just to omit a single field from the `==` consideration; this is another 
>>> sense in which you can say deriving is an all-or-none; there’s just no way 
>>> to invoke the synthesis mechanism other than for "all fields”.
>> 
>> I don’t see why this must necessarily be the case.  Annotations such as you 
>> describe below could be taken into account by `deriving`.  `deriving` is 
>> just a way to invoke the synthesis mechanism.
> 
> Different people are using it differently I think; I agree with you if it’s 
> just the name of the invocation, but I think at least some people are using 
> it as a shorthand for the “naive” implementation (all fields equatable => 
> equatable).
> 
> That is, I meant "naive deriving” to refer to something like this (quoting 
> Patrick):
> 
>> It would fail if not all members were Equatable or Hashable. If it was 
>> automatic, you wouldn’t get any warning or sign at all. If you have to 
>> explicitly conform to the protocols, then your intention is clear, and if an 
>> automatic implementation cannot be made (because not all members were 
>> Equatable or Hashable), then you will get an error that you need to 
>> implement the protocol yourself like you do now (i.e. implement == and 
>> hashValue).
> 
> 
> …but I could’ve been clearer!
> 
>> 
>>> 
>>> On the one hand, it’s possible to imagine a finer-grained form of this 
>>> synthesis that’d allow you to e.g. indicate a certain field should be 
>>> omitted (and also perhaps specialize how fields are compared, customize the 
>>> synthesized comparison ordering to put cheaper comparisons earlier, and an 
>>> endless list of other possible requests…).
>> 
>> If you don’t trust the compiler to optimize this well and therefore want 
>> control over order of comparisons you should probably just implement it 
>> manually.  As you note below, this is a convenience feature that needs to 
>> strike a fine balance.
> 
> I agree, but at the same time i think that scenarios like this:
> 
>   struct RevisionInfo {
> let contentID: NSUUID
> let 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Matthew Johnson via swift-evolution]

> On May 27, 2016, at 5:07 PM, plx via swift-evolution 
>  wrote:
> 
>   
>> On May 27, 2016, at 3:22 PM, Ricardo Parada via swift-evolution 
>> > wrote:
>> 
>> Inline
>> 
>> 
>> On May 27, 2016, at 2:52 PM, Matthew Johnson > > wrote:
>> 
>>> 
 On May 27, 2016, at 12:48 PM, Ricardo Parada > wrote:
 
 
 What if we get the error when trying to use it?  For example, if a struct 
 uses a value that is not Equatable / Hashable then it would not be 
 Equatable / Hashable and you would not find out until you tried to use it. 
  Would that be bad?
>>> 
>>> Yes.  It would also be bad if implicit synthesis resulted in an 
>>> unintentional and incorrect definition of equality.  By requiring synthesis 
>>> to be requested with `deriving` the programmer is at least prompted to 
>>> consider the meaning of equality for their type.
>> 
>> Incorrect definition of equality? Hmm... :-)
>> 
>> I guess I have been running under the wrong assumption that if a struct uses 
>> values that are all Equatable then the default implementation for the struct 
>> which will compare the values against the values in the other struct will 
>> ALWAYS be correct. But I guess I can come up with an example where some of 
>> the values stored in the struct do not play a role in the definition of 
>> equality even if those values are Equatable. Then the default implementation 
>> would be incorrect. 
> 
> A recent one for me was a rational type, e.g. you’d want things like `1/2 == 
> 2/4` (and in this case I didn’t want an implementation that *would* always 
> automatically use fully-reduced internal representations).

It’s a bit of a tangent, but you might want to take a look at John Lakos’ 
discussion of rational equality in the talk Dave A posted a link to.  There are 
subtle differences in behavior (overflow, etc) between 1/2 and 2/4.  They are 
not actually substitutable when you have bounded integer types.  John makes 
some interesting observations on this topic.

> 
> I *do* think Swift is missing a “bit-by-bit/physical" equality operator (for 
> which 1/2 and 2/4 would be distinct, here), and Swift should probably get one 
> at some point, but that’s IMHO another (but related) discussion.
> 
>> But I am not convince that is bad because   that can happen regardless of 
>> whether equatable is an opt-in thing or automatic. For example, let's say 
>> you opt-in by saying that it implements Equatable or by using the derived / 
>> synthesizes keyword that we have mentioned. The developer may not realize 
>> until later that the default implementation would be wrong for your 
>> fancy/unusual struct.  It is likely that opting in may raise a flag in your 
>> brain that says "hey, is the default implementation going to do the right 
>> thing? Do you need to customize it for your struct?" But it's not a 
>> guarantee either. And if it's not a guarantee then should it be automatic 
>> then? Most developer will go with the default implementation when they 
>> opt-in and then realize later that they may need to customize when things 
>> are not working quite the way the expected. 
>> 
>> 
 
 
> On May 26, 2016, at 11:35 AM, Matthew Johnson via swift-evolution 
> > wrote:
> 
>> 
>> On May 26, 2016, at 10:18 AM, T.J. Usiyan via swift-evolution 
>> > 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 deriving 
>> Equatable` will make every `Shape` equatable if `X` is equatable. But 
>> if `X` is not equatable, `Shape` can be used as well. 
> 
> 
> You should not be able to just say `struct Shape 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.
> 
>> 
>> On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution 
>> > wrote:
>> Can we just copy the solution from Haskell instead of creating our 
>> own? It's just better in every aspect. Deriving 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[plx via swift-evolution]

> On May 27, 2016, at 3:22 PM, Ricardo Parada via swift-evolution 
>  wrote:
> 
> Inline
> 
> 
> On May 27, 2016, at 2:52 PM, Matthew Johnson  > wrote:
> 
>> 
>>> On May 27, 2016, at 12:48 PM, Ricardo Parada >> > wrote:
>>> 
>>> 
>>> What if we get the error when trying to use it?  For example, if a struct 
>>> uses a value that is not Equatable / Hashable then it would not be 
>>> Equatable / Hashable and you would not find out until you tried to use it.  
>>> Would that be bad?
>> 
>> Yes.  It would also be bad if implicit synthesis resulted in an 
>> unintentional and incorrect definition of equality.  By requiring synthesis 
>> to be requested with `deriving` the programmer is at least prompted to 
>> consider the meaning of equality for their type.
> 
> Incorrect definition of equality? Hmm... :-)
> 
> I guess I have been running under the wrong assumption that if a struct uses 
> values that are all Equatable then the default implementation for the struct 
> which will compare the values against the values in the other struct will 
> ALWAYS be correct. But I guess I can come up with an example where some of 
> the values stored in the struct do not play a role in the definition of 
> equality even if those values are Equatable. Then the default implementation 
> would be incorrect. 

A recent one for me was a rational type, e.g. you’d want things like `1/2 == 
2/4` (and in this case I didn’t want an implementation that *would* always 
automatically use fully-reduced internal representations).

I *do* think Swift is missing a “bit-by-bit/physical" equality operator (for 
which 1/2 and 2/4 would be distinct, here), and Swift should probably get one 
at some point, but that’s IMHO another (but related) discussion.

> But I am not convince that is bad because   that can happen regardless of 
> whether equatable is an opt-in thing or automatic. For example, let's say you 
> opt-in by saying that it implements Equatable or by using the derived / 
> synthesizes keyword that we have mentioned. The developer may not realize 
> until later that the default implementation would be wrong for your 
> fancy/unusual struct.  It is likely that opting in may raise a flag in your 
> brain that says "hey, is the default implementation going to do the right 
> thing? Do you need to customize it for your struct?" But it's not a guarantee 
> either. And if it's not a guarantee then should it be automatic then? Most 
> developer will go with the default implementation when they opt-in and then 
> realize later that they may need to customize when things are not working 
> quite the way the expected. 
> 
> 
>>> 
>>> 
 On May 26, 2016, at 11:35 AM, Matthew Johnson via swift-evolution 
 > wrote:
 
> 
> On May 26, 2016, at 10:18 AM, T.J. Usiyan via swift-evolution 
> > 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 deriving 
> Equatable` will make every `Shape` equatable if `X` is equatable. But 
> if `X` is not equatable, `Shape` can be used as well. 
 
 
 You should not be able to just say `struct Shape 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.
 
> 
> On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution 
> > wrote:
> Can we just copy the solution from Haskell instead of creating our 
> own? It's just better in every aspect. Deriving `Equatable` and 
> `Hashable` would become
> 
> struct Polygon deriving Equatable, Hashable {
> ...
> }
> 
> This has several advantages:
> - you don't have to guess wether `Equatable` or `Hashable` should be 
> automatically derived or not.
> - Deriving becomes an explicit choice.
> - If you need a custom `Equatable` implementation (for whatever reason), 
> you can still do it.
> - It doesn't break any code that is unaware of the change
> - It can be extended in future versions of Swift, without introducing any 
> new 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Matthew Johnson via swift-evolution]

> On May 27, 2016, at 3:22 PM, Ricardo Parada  wrote:
> 
> Inline
> 
> 
> On May 27, 2016, at 2:52 PM, Matthew Johnson  > wrote:
> 
>> 
>>> On May 27, 2016, at 12:48 PM, Ricardo Parada >> > wrote:
>>> 
>>> 
>>> What if we get the error when trying to use it?  For example, if a struct 
>>> uses a value that is not Equatable / Hashable then it would not be 
>>> Equatable / Hashable and you would not find out until you tried to use it.  
>>> Would that be bad?
>> 
>> Yes.  It would also be bad if implicit synthesis resulted in an 
>> unintentional and incorrect definition of equality.  By requiring synthesis 
>> to be requested with `deriving` the programmer is at least prompted to 
>> consider the meaning of equality for their type.
> 
> Incorrect definition of equality? Hmm... :-)
> 
> I guess I have been running under the wrong assumption that if a struct uses 
> values that are all Equatable then the default implementation for the struct 
> which will compare the values against the values in the other struct will 
> ALWAYS be correct. But I guess I can come up with an example where some of 
> the values stored in the struct do not play a role in the definition of 
> equality even if those values are Equatable. Then the default implementation 
> would be incorrect. 
> 
> But I am not convince that is bad because   that can happen regardless of 
> whether equatable is an opt-in thing or automatic. For example, let's say you 
> opt-in by saying that it implements Equatable or by using the derived / 
> synthesizes keyword that we have mentioned. The developer may not realize 
> until later that the default implementation would be wrong for your 
> fancy/unusual struct.  It is likely that opting in may raise a flag in your 
> brain that says "hey, is the default implementation going to do the right 
> thing? Do you need to customize it for your struct?" But it's not a guarantee 
> either. And if it's not a guarantee then should it be automatic then?

No, I don’t think so.  Opting in localizes any errors and also prompts the 
developer to consider what the synthesized implementation will do.

> Most developer will go with the default implementation when they opt-in and 
> then realize later that they may need to customize when things are not 
> working quite the way the expected. 

This is exactly why opting in is the right way to go.  It may not prevent all 
developers from such mistakes, but it might help some, especially those who 
understand the issues involved but may *forget* to consider the issues if they 
don’t have to type `deriving Equatable, Hashable`.

> 
> 
>>> 
>>> 
 On May 26, 2016, at 11:35 AM, Matthew Johnson via swift-evolution 
 > wrote:
 
> 
> On May 26, 2016, at 10:18 AM, T.J. Usiyan via swift-evolution 
> > 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 deriving 
> Equatable` will make every `Shape` equatable if `X` is equatable. But 
> if `X` is not equatable, `Shape` can be used as well. 
 
 
 You should not be able to just say `struct Shape 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.
 
> 
> On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution 
> > wrote:
> Can we just copy the solution from Haskell instead of creating our 
> own? It's just better in every aspect. Deriving `Equatable` and 
> `Hashable` would become
> 
> struct Polygon deriving Equatable, Hashable {
> ...
> }
> 
> This has several advantages:
> - you don't have to guess wether `Equatable` or `Hashable` should be 
> automatically derived or not.
> - Deriving becomes an explicit choice.
> - If you need a custom `Equatable` implementation (for whatever reason), 
> you can still do it.
> - It doesn't break any code that is unaware of the change
> - It can be extended in future versions of Swift, without introducing any 
> new incompatibilities. For example, 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Ricardo Parada via swift-evolution]

Inline


> On May 27, 2016, at 2:52 PM, Matthew Johnson  wrote:
> 
> 
>> On May 27, 2016, at 12:48 PM, Ricardo Parada  wrote:
>> 
>> 
>> What if we get the error when trying to use it?  For example, if a struct 
>> uses a value that is not Equatable / Hashable then it would not be Equatable 
>> / Hashable and you would not find out until you tried to use it.  Would that 
>> be bad?
> 
> Yes.  It would also be bad if implicit synthesis resulted in an unintentional 
> and incorrect definition of equality.  By requiring synthesis to be requested 
> with `deriving` the programmer is at least prompted to consider the meaning 
> of equality for their type.

Incorrect definition of equality? Hmm... :-)

I guess I have been running under the wrong assumption that if a struct uses 
values that are all Equatable then the default implementation for the struct 
which will compare the values against the values in the other struct will 
ALWAYS be correct. But I guess I can come up with an example where some of the 
values stored in the struct do not play a role in the definition of equality 
even if those values are Equatable. Then the default implementation would be 
incorrect. 

But I am not convince that is bad because   that can happen regardless of 
whether equatable is an opt-in thing or automatic. For example, let's say you 
opt-in by saying that it implements Equatable or by using the derived / 
synthesizes keyword that we have mentioned. The developer may not realize until 
later that the default implementation would be wrong for your fancy/unusual 
struct.  It is likely that opting in may raise a flag in your brain that says 
"hey, is the default implementation going to do the right thing? Do you need to 
customize it for your struct?" But it's not a guarantee either. And if it's not 
a guarantee then should it be automatic then? Most developer will go with the 
default implementation when they opt-in and then realize later that they may 
need to customize when things are not working quite the way the expected. 


>> 
>> 
 On May 26, 2016, at 11:35 AM, Matthew Johnson via swift-evolution 
  wrote:
 
 
 On May 26, 2016, at 10:18 AM, T.J. Usiyan via swift-evolution 
  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 deriving 
 Equatable` will make every `Shape` equatable if `X` is equatable. But 
 if `X` is not equatable, `Shape` can be used as well. 
>>> 
>>> 
>>> You should not be able to just say `struct Shape 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.
>>> 
 
> On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution 
>  wrote:
> Can we just copy the solution from Haskell instead of creating our 
> own? It's just better in every aspect. Deriving `Equatable` and 
> `Hashable` would become
> 
> struct Polygon deriving Equatable, Hashable {
> ...
> }
> 
> This has several advantages:
> - you don't have to guess wether `Equatable` or `Hashable` should be 
> automatically derived or not.
> - Deriving becomes an explicit choice.
> - If you need a custom `Equatable` implementation (for whatever reason), 
> you can still do it.
> - It doesn't break any code that is unaware of the change
> - It can be extended in future versions of Swift, without introducing any 
> new incompatibilities. For example, `CustomStringConvertible` could be 
> derived just as easily.
> - It is compatible with generics. E.g. `struct Shape deriving 
> Equatable` will make every `Shape` equatable if `X` is equatable. But 
> if `X` is not equatable, `Shape` can be used as well. (Unless `X` is 
> not used, in which case every `Shape` would be equatable. Unless 
> something in the definition of `Shape` makes deriving `Equatable` 
> impossible => this produces an error.)
> - It is proven to work in production.
> 
> -Michael
> 
> > Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
> > :
> >
> > Thanks so much for putting this together, Tony! Glad I was able to be 
> > some inspiration. :^)
> >
> >

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[plx via swift-evolution]

> On May 27, 2016, at 10:48 AM, Matthew Johnson  wrote:
> 
>> 
>> On May 27, 2016, at 10:37 AM, plx via swift-evolution 
>> > wrote:
>> 
>> 
>>> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution 
>>> > wrote:
>>> 
>>> A `deriving` keyword, at the very least, is pretty explicitly *not* an 
>>> all-or-nothing situation. If you want to define equality/hashability for 
>>> your type manually, don't use `deriving`. This should leave the simplest 
>>> cases to auto generation and anything more complex should be handled by the 
>>> developer.
>> 
>> It’s all-or-nothing in the sense you can’t use a naive `deriving` 
>> implementation to assist in any case where what you need is *almost* the 
>> trivial implementation, but not quite.
>> 
>> Consider a case like this:
>> 
>>   class QuxEvaluator  {
>>   
>> let foo: Foo // Equatable
>> let bar: Bar // Equatable
>> let baz: Baz // Equatable
>> 
>> private var quxCache: [QuxIdentifier:Qux] // [Equatable:Equatable] = [:]
>> 
>> // pure function of `foo`, `bar`, `baz`, and `identifier`
>> // expensive, and uses `quxCache` for memoization 
>> func qux(for identifier: QuxIdentifier) -> Qux
>> 
>>   }
>> 
>> …if it weren’t for `quxCache` we could easily synthesize `==` for 
>> `QuxEvaluator`, but the trivial synthesis will yield invalid results due to 
>> `[QuxIdentifier:Qux]` also being `Equatable` (really: it *will* also be 
>> equatable once conditional conformances are in place).
>> 
>> So we’re back to e.g. writing this: 
>> 
>>   extension QuxEvaluator : Equatable {
>> 
>>   }
>> 
>>   func ==(lhs: QuxEvaluator, rhs: QuxEvaluator) -> Bool {
>> return (lhs === rhs) || (lhs.foo == rhs.foo && lhs.bar == rhs.bar && 
>> lhs.baz == rhs.baz)
>>   }
>> 
>> …just to omit a single field from the `==` consideration; this is another 
>> sense in which you can say deriving is an all-or-none; there’s just no way 
>> to invoke the synthesis mechanism other than for "all fields”.
> 
> I don’t see why this must necessarily be the case.  Annotations such as you 
> describe below could be taken into account by `deriving`.  `deriving` is just 
> a way to invoke the synthesis mechanism.

Different people are using it differently I think; I agree with you if it’s 
just the name of the invocation, but I think at least some people are using it 
as a shorthand for the “naive” implementation (all fields equatable => 
equatable).

That is, I meant "naive deriving” to refer to something like this (quoting 
Patrick):

> It would fail if not all members were Equatable or Hashable. If it was 
> automatic, you wouldn’t get any warning or sign at all. If you have to 
> explicitly conform to the protocols, then your intention is clear, and if an 
> automatic implementation cannot be made (because not all members were 
> Equatable or Hashable), then you will get an error that you need to implement 
> the protocol yourself like you do now (i.e. implement == and hashValue).


…but I could’ve been clearer!

> 
>> 
>> On the one hand, it’s possible to imagine a finer-grained form of this 
>> synthesis that’d allow you to e.g. indicate a certain field should be 
>> omitted (and also perhaps specialize how fields are compared, customize the 
>> synthesized comparison ordering to put cheaper comparisons earlier, and an 
>> endless list of other possible requests…).
> 
> If you don’t trust the compiler to optimize this well and therefore want 
> control over order of comparisons you should probably just implement it 
> manually.  As you note below, this is a convenience feature that needs to 
> strike a fine balance.

I agree, but at the same time i think that scenarios like this:

  struct RevisionInfo {
let contentID: NSUUID
let revisionID: NSUUID
let contentData: NSData
  }

…aren’t going to be all that uncommon in practice; I think a good “layered” 
implementation of the derivation/synthesis logic would suffice (e.g. we 
wouldn't *need* special-case handling for ordering, potentially…).

> 
> IMO there are two issues involved:
> 
> 1. How do we invoke the automatic synthesis.
> 2. How do we have some degree of control over the synthesis that happens.
> 
> `deriving` addresses issue 1 and says nothing about issue 2.

Agreed here; 2 is the interesting question. If you look at my initial response 
in this thread I tried to suggest a “layered” approach:

Layer A: have some way of directly invoking the synthesis mechanism itself 
(e.g. as a special-purpose macro-like construct); it should be powerful enough 
to make `==` easy to write, but have some flexibility (implemented or 
planned-for-future).

Layer B: add a way to synthesize `==` (etc.) via the construct from Layer A.
 
That’s my 2c on this topic; given it’s a Swift 4 topic at the very earliest 
there’s a lot of time to figure it 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Matthew Johnson via swift-evolution]

> On May 27, 2016, at 12:48 PM, Ricardo Parada  wrote:
> 
> 
> What if we get the error when trying to use it?  For example, if a struct 
> uses a value that is not Equatable / Hashable then it would not be Equatable 
> / Hashable and you would not find out until you tried to use it.  Would that 
> be bad?

Yes.  It would also be bad if implicit synthesis resulted in an unintentional 
and incorrect definition of equality.  By requiring synthesis to be requested 
with `deriving` the programmer is at least prompted to consider the meaning of 
equality for their type.

> 
> 
>> On May 26, 2016, at 11:35 AM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On May 26, 2016, at 10:18 AM, T.J. Usiyan via swift-evolution 
>>> > 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 deriving Equatable` 
>>> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
>>> equatable, `Shape` can be used as well. 
>> 
>> 
>> You should not be able to just say `struct Shape 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.
>> 
>>> 
>>> On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution 
>>> > wrote:
>>> Can we just copy the solution from Haskell instead of creating our 
>>> own? It's just better in every aspect. Deriving `Equatable` and `Hashable` 
>>> would become
>>> 
>>> struct Polygon deriving Equatable, Hashable {
>>> ...
>>> }
>>> 
>>> This has several advantages:
>>> - you don't have to guess wether `Equatable` or `Hashable` should be 
>>> automatically derived or not.
>>> - Deriving becomes an explicit choice.
>>> - If you need a custom `Equatable` implementation (for whatever reason), 
>>> you can still do it.
>>> - It doesn't break any code that is unaware of the change
>>> - It can be extended in future versions of Swift, without introducing any 
>>> new incompatibilities. For example, `CustomStringConvertible` could be 
>>> derived just as easily.
>>> - It is compatible with generics. E.g. `struct Shape deriving Equatable` 
>>> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
>>> equatable, `Shape` can be used as well. (Unless `X` is not used, in 
>>> which case every `Shape` would be equatable. Unless something in the 
>>> definition of `Shape` makes deriving `Equatable` impossible => this 
>>> produces an error.)
>>> - It is proven to work in production.
>>> 
>>> -Michael
>>> 
>>> > Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
>>> > >:
>>> >
>>> > Thanks so much for putting this together, Tony! Glad I was able to be 
>>> > some inspiration. :^)
>>> >
>>> >
>>> > On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
>>> > > wrote:
>>> > I was inspired to put together a draft proposal based on an older 
>>> > discussion in the Universal Equality, Hashability, and Comparability 
>>> > thread >> > > that 
>>> > recently got necromanced (thanks Mark Sands!).
>>> >
>>> > I'm guessing that this would be a significant enough change that it's not 
>>> > possible for the Swift 3 timeline, but it's something that would benefit 
>>> > enough people that I want to make sure the discussion stays alive. If 
>>> > there are enough good feelings about it, I'll move it from my gist into 
>>> > an actual proposal PR.
>>> >
>>> > Automatically deriving Equatable andHashable for value types
>>> >
>>> >   • Proposal: SE-
>>> >   • Author(s): Tony Allevato
>>> >   • Status: Awaiting review
>>> >   • Review manager: TBD
>>> > Introduction
>>> >
>>> > Value types are prevalent throughout the Swift language, and we encourage 
>>> > developers to think in those terms when writing their own types. 
>>> > Frequently, developers find themselves writing large amounts of 
>>> > boilerplate code to support equatability and hashability of value types. 
>>> > This proposal offers a way for the compiler to 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Ricardo Parada via swift-evolution]

What if we get the error when trying to use it?  For example, if a struct uses 
a value that is not Equatable / Hashable then it would not be Equatable / 
Hashable and you would not find out until you tried to use it.  Would that be 
bad?


> On May 26, 2016, at 11:35 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> 
>> On May 26, 2016, at 10:18 AM, T.J. Usiyan via swift-evolution 
>> > 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 deriving Equatable` 
>> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
>> equatable, `Shape` can be used as well. 
> 
> 
> You should not be able to just say `struct Shape 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.
> 
>> 
>> On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution 
>> > wrote:
>> Can we just copy the solution from Haskell instead of creating our 
>> own? It's just better in every aspect. Deriving `Equatable` and `Hashable` 
>> would become
>> 
>> struct Polygon deriving Equatable, Hashable {
>> ...
>> }
>> 
>> This has several advantages:
>> - you don't have to guess wether `Equatable` or `Hashable` should be 
>> automatically derived or not.
>> - Deriving becomes an explicit choice.
>> - If you need a custom `Equatable` implementation (for whatever reason), you 
>> can still do it.
>> - It doesn't break any code that is unaware of the change
>> - It can be extended in future versions of Swift, without introducing any 
>> new incompatibilities. For example, `CustomStringConvertible` could be 
>> derived just as easily.
>> - It is compatible with generics. E.g. `struct Shape deriving Equatable` 
>> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
>> equatable, `Shape` can be used as well. (Unless `X` is not used, in which 
>> case every `Shape` would be equatable. Unless something in the definition 
>> of `Shape` makes deriving `Equatable` impossible => this produces an error.)
>> - It is proven to work in production.
>> 
>> -Michael
>> 
>> > Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
>> > >:
>> >
>> > Thanks so much for putting this together, Tony! Glad I was able to be some 
>> > inspiration. :^)
>> >
>> >
>> > On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
>> > > wrote:
>> > I was inspired to put together a draft proposal based on an older 
>> > discussion in the Universal Equality, Hashability, and Comparability 
>> > thread > > > that 
>> > recently got necromanced (thanks Mark Sands!).
>> >
>> > I'm guessing that this would be a significant enough change that it's not 
>> > possible for the Swift 3 timeline, but it's something that would benefit 
>> > enough people that I want to make sure the discussion stays alive. If 
>> > there are enough good feelings about it, I'll move it from my gist into an 
>> > actual proposal PR.
>> >
>> > Automatically deriving Equatable andHashable for value types
>> >
>> >   • Proposal: SE-
>> >   • Author(s): Tony Allevato
>> >   • Status: Awaiting review
>> >   • Review manager: TBD
>> > Introduction
>> >
>> > Value types are prevalent throughout the Swift language, and we encourage 
>> > developers to think in those terms when writing their own types. 
>> > Frequently, developers find themselves writing large amounts of 
>> > boilerplate code to support equatability and hashability of value types. 
>> > This proposal offers a way for the compiler to automatically derive 
>> > conformance toEquatable and Hashable to reduce this boilerplate, in a 
>> > subset of scenarios where generating the correct implementation is likely 
>> > to be possible.
>> >
>> > Swift-evolution thread: Universal Equatability, Hashability, and 
>> > Comparability
>> >
>> > Motivation
>> >
>> > Building robust value types in Swift can involve writing significant 
>> > boilerplate code to support concepts of hashability and equatability. 
>> > Equality is pervasive 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Patrick Smith via swift-evolution]

It would fail if not all members were Equatable or Hashable. If it was 
automatic, you wouldn’t get any warning or sign at all. If you have to 
explicitly conform to the protocols, then your intention is clear, and if an 
automatic implementation cannot be made (because not all members were Equatable 
or Hashable), then you will get an error that you need to implement the 
protocol yourself like you do now (i.e. implement == and hashValue).

Patrick

> On 28 May 2016, at 1:38 AM, Ricardo Parada  wrote:
> 
> When would the automatic implementation fail?
> 
> I see your point about adding to the compile size and I had previously 
> mentioned that. Usually in the apps I develop that is not a concern. However 
> I can see it could be a concern for apps that are more restrictive. If Swift 
> is to be used to build such apps too then I agree that not being automatic 
> would be important. It would have to be opt-in. I would be okay with that 
> solution. Hopefully most would make use of it in high-level frameworks.
> 
> I guess similar to reflection and enabling dynamism. I look forward to 
> eventually being able to do key-value-coding in pure Swift and being able to 
> implement a framework similar to WebObjects which would require being able to 
> find properties by their name, getting and setting values. That would be 
> another example of opting in for a richer run-time. 
> 
> 
> On May 27, 2016, at 10:11 AM, Patrick Smith  > wrote:
> 
>> If you have to specify Equatable / Hashable, then you can get an error if 
>> the automatic implementation failed, due to a member also not being 
>> Equatable/Hashable. If it’s automatic, then it will just quietly fail, 
>> making problems harder to know about and track. It will also always add to 
>> the compile size, even if you didn’t want the functionality.
>> 
>> 
>>> On 27 May 2016, at 10:46 PM, Ricardo Parada >> > wrote:
>>> 
>>> I agree, I think there is no need for deriving/synthesizes, but also, no 
>>> need to specify Equatable, Hashable. They should get the functionality by 
>>> default but allow for override and customization. 
>>> 
>>> 
>>> On May 26, 2016, at 11:02 PM, Patrick Smith >> > wrote:
>>> 
 I don’t understand why you couldn’t conform to Equatable, and if it 
 fulfils the requirements (all members are also Equatable), then its 
 implementation is automatically created for you. That way you don’t need a 
 new keyword. It’s like Objective-C’s property automatic synthesising that 
 get used unless you implement ones yourself.
 
 
> On 27 May 2016, at 12:57 PM, Ricardo Parada via swift-evolution 
> > wrote:
> 
> 
> 
> I wonder if synthesizes would be a better choice than deriving. 
> 
> 
> 
> On May 26, 2016, at 5:58 AM, Michael Peternell via swift-evolution 
> > wrote:
> 
>> Can we just copy the solution from Haskell instead of creating our 
>> own? It's just better in every aspect. Deriving `Equatable` and 
>> `Hashable` would become
>> 
>> struct Polygon deriving Equatable, Hashable {
>>...
>> }
>> 
>> This has several advantages:
>> - you don't have to guess wether `Equatable` or `Hashable` should be 
>> automatically derived or not.
>> - Deriving becomes an explicit choice.
>> - If you need a custom `Equatable` implementation (for whatever reason), 
>> you can still do it.
>> - It doesn't break any code that is unaware of the change
>> - It can be extended in future versions of Swift, without introducing 
>> any new incompatibilities. For example, `CustomStringConvertible` could 
>> be derived just as easily.
>> - It is compatible with generics. E.g. `struct Shape deriving 
>> Equatable` will make every `Shape` equatable if `X` is equatable. But 
>> if `X` is not equatable, `Shape` can be used as well. (Unless `X` is 
>> not used, in which case every `Shape` would be equatable. Unless 
>> something in the definition of `Shape` makes deriving `Equatable` 
>> impossible => this produces an error.)
>> - It is proven to work in production.
>> 
>> -Michael
>> 
>>> Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
>>> >:
>>> 
>>> Thanks so much for putting this together, Tony! Glad I was able to be 
>>> some inspiration. :^)
>>> 
>>> 
>>> On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
>>> > wrote:
>>> I was inspired to put together a draft proposal based on an older 
>>> discussion in the 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Matthew Johnson via swift-evolution]

> On May 27, 2016, at 10:37 AM, plx via swift-evolution 
>  wrote:
> 
> 
>> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution 
>> > wrote:
>> 
>> A `deriving` keyword, at the very least, is pretty explicitly *not* an 
>> all-or-nothing situation. If you want to define equality/hashability for 
>> your type manually, don't use `deriving`. This should leave the simplest 
>> cases to auto generation and anything more complex should be handled by the 
>> developer.
> 
> It’s all-or-nothing in the sense you can’t use a naive `deriving` 
> implementation to assist in any case where what you need is *almost* the 
> trivial implementation, but not quite.
> 
> Consider a case like this:
> 
>   class QuxEvaluator  {
>   
> let foo: Foo // Equatable
> let bar: Bar // Equatable
> let baz: Baz // Equatable
> 
> private var quxCache: [QuxIdentifier:Qux] // [Equatable:Equatable] = [:]
> 
> // pure function of `foo`, `bar`, `baz`, and `identifier`
> // expensive, and uses `quxCache` for memoization 
> func qux(for identifier: QuxIdentifier) -> Qux
> 
>   }
> 
> …if it weren’t for `quxCache` we could easily synthesize `==` for 
> `QuxEvaluator`, but the trivial synthesis will yield invalid results due to 
> `[QuxIdentifier:Qux]` also being `Equatable` (really: it *will* also be 
> equatable once conditional conformances are in place).
> 
> So we’re back to e.g. writing this: 
> 
>   extension QuxEvaluator : Equatable {
> 
>   }
> 
>   func ==(lhs: QuxEvaluator, rhs: QuxEvaluator) -> Bool {
> return (lhs === rhs) || (lhs.foo == rhs.foo && lhs.bar == rhs.bar && 
> lhs.baz == rhs.baz)
>   }
> 
> …just to omit a single field from the `==` consideration; this is another 
> sense in which you can say deriving is an all-or-none; there’s just no way to 
> invoke the synthesis mechanism other than for "all fields”.

I don’t see why this must necessarily be the case.  Annotations such as you 
describe below could be taken into account by `deriving`.  `deriving` is just a 
way to invoke the synthesis mechanism.

> 
> On the one hand, it’s possible to imagine a finer-grained form of this 
> synthesis that’d allow you to e.g. indicate a certain field should be omitted 
> (and also perhaps specialize how fields are compared, customize the 
> synthesized comparison ordering to put cheaper comparisons earlier, and an 
> endless list of other possible requests…).

If you don’t trust the compiler to optimize this well and therefore want 
control over order of comparisons you should probably just implement it 
manually.  As you note below, this is a convenience feature that needs to 
strike a fine balance.

IMO there are two issues involved:

1. How do we invoke the automatic synthesis.
2. How do we have some degree of control over the synthesis that happens.

`deriving` addresses issue 1 and says nothing about issue 2.

> 
> On the other hand, the memberwise-init proposal had a very similar situation: 
> the naive approach was arguably too narrow, but it proved very difficult to 
> find a workable balance between customization and implementation complexity 
> (leaving it postponed for the foreseeable future); it’d be a pity if 
> synthesis like this fell into the same trap.
> 
> But, on the gripping hand, I highly suspect that a naive `deriving`/synthesis 
> will wind up being too narrowly-useful to really justify; that’s just my 
> opinion, of course.
> 
>> 
>> On Thu, May 26, 2016 at 11:20 AM, L. Mihalkovic 
>> > wrote:
>> what i care about is to have a choice about what DEFINES the identity of my 
>> values, not just an all-or-nothing situation.
>> 
>> On May 26, 2016, at 5:18 PM, T.J. Usiyan via swift-evolution 
>> > wrote:
>> 
>>> +1 to a `deriving` keyword
>>> 
>>> On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution 
>>> > wrote:
>>> Can we just copy the solution from Haskell instead of creating our 
>>> own? It's just better in every aspect. Deriving `Equatable` and `Hashable` 
>>> would become
>>> 
>>> struct Polygon deriving Equatable, Hashable {
>>> ...
>>> }
>>> 
>>> This has several advantages:
>>> - you don't have to guess wether `Equatable` or `Hashable` should be 
>>> automatically derived or not.
>>> - Deriving becomes an explicit choice.
>>> - If you need a custom `Equatable` implementation (for whatever reason), 
>>> you can still do it.
>>> - It doesn't break any code that is unaware of the change
>>> - It can be extended in future versions of Swift, without introducing any 
>>> new incompatibilities. For example, `CustomStringConvertible` could be 
>>> derived just as easily.
>>> - It is compatible with generics. E.g. `struct Shape deriving Equatable` 
>>> will make every `Shape` 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[plx via swift-evolution]

> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> A `deriving` keyword, at the very least, is pretty explicitly *not* an 
> all-or-nothing situation. If you want to define equality/hashability for your 
> type manually, don't use `deriving`. This should leave the simplest cases to 
> auto generation and anything more complex should be handled by the developer.

It’s all-or-nothing in the sense you can’t use a naive `deriving` 
implementation to assist in any case where what you need is *almost* the 
trivial implementation, but not quite.

Consider a case like this:

  class QuxEvaluator  {
  
let foo: Foo // Equatable
let bar: Bar // Equatable
let baz: Baz // Equatable

private var quxCache: [QuxIdentifier:Qux] // [Equatable:Equatable] = [:]

// pure function of `foo`, `bar`, `baz`, and `identifier`
// expensive, and uses `quxCache` for memoization 
func qux(for identifier: QuxIdentifier) -> Qux

  }

…if it weren’t for `quxCache` we could easily synthesize `==` for 
`QuxEvaluator`, but the trivial synthesis will yield invalid results due to 
`[QuxIdentifier:Qux]` also being `Equatable` (really: it *will* also be 
equatable once conditional conformances are in place).

So we’re back to e.g. writing this: 

  extension QuxEvaluator : Equatable {

  }

  func ==(lhs: QuxEvaluator, rhs: QuxEvaluator) -> Bool {
return (lhs === rhs) || (lhs.foo == rhs.foo && lhs.bar == rhs.bar && 
lhs.baz == rhs.baz)
  }

…just to omit a single field from the `==` consideration; this is another sense 
in which you can say deriving is an all-or-none; there’s just no way to invoke 
the synthesis mechanism other than for "all fields”.

On the one hand, it’s possible to imagine a finer-grained form of this 
synthesis that’d allow you to e.g. indicate a certain field should be omitted 
(and also perhaps specialize how fields are compared, customize the synthesized 
comparison ordering to put cheaper comparisons earlier, and an endless list of 
other possible requests…).

On the other hand, the memberwise-init proposal had a very similar situation: 
the naive approach was arguably too narrow, but it proved very difficult to 
find a workable balance between customization and implementation complexity 
(leaving it postponed for the foreseeable future); it’d be a pity if synthesis 
like this fell into the same trap.

But, on the gripping hand, I highly suspect that a naive `deriving`/synthesis 
will wind up being too narrowly-useful to really justify; that’s just my 
opinion, of course.

> 
> On Thu, May 26, 2016 at 11:20 AM, L. Mihalkovic  > wrote:
> what i care about is to have a choice about what DEFINES the identity of my 
> values, not just an all-or-nothing situation.
> 
> On May 26, 2016, at 5:18 PM, T.J. Usiyan via swift-evolution 
> > wrote:
> 
>> +1 to a `deriving` keyword
>> 
>> On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution 
>> > wrote:
>> Can we just copy the solution from Haskell instead of creating our 
>> own? It's just better in every aspect. Deriving `Equatable` and `Hashable` 
>> would become
>> 
>> struct Polygon deriving Equatable, Hashable {
>> ...
>> }
>> 
>> This has several advantages:
>> - you don't have to guess wether `Equatable` or `Hashable` should be 
>> automatically derived or not.
>> - Deriving becomes an explicit choice.
>> - If you need a custom `Equatable` implementation (for whatever reason), you 
>> can still do it.
>> - It doesn't break any code that is unaware of the change
>> - It can be extended in future versions of Swift, without introducing any 
>> new incompatibilities. For example, `CustomStringConvertible` could be 
>> derived just as easily.
>> - It is compatible with generics. E.g. `struct Shape deriving Equatable` 
>> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
>> equatable, `Shape` can be used as well. (Unless `X` is not used, in which 
>> case every `Shape` would be equatable. Unless something in the definition 
>> of `Shape` makes deriving `Equatable` impossible => this produces an error.)
>> - It is proven to work in production.
>> 
>> -Michael
>> 
>> > Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
>> > >:
>> >
>> > Thanks so much for putting this together, Tony! Glad I was able to be some 
>> > inspiration. :^)
>> >
>> >
>> > On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
>> > > wrote:
>> > I was inspired to put together a draft proposal based on an older 
>> > discussion in the Universal Equality, Hashability, and Comparability 
>> > thread 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Ricardo Parada via swift-evolution]

When would the automatic implementation fail?

I see your point about adding to the compile size and I had previously 
mentioned that. Usually in the apps I develop that is not a concern. However I 
can see it could be a concern for apps that are more restrictive. If Swift is 
to be used to build such apps too then I agree that not being automatic would 
be important. It would have to be opt-in. I would be okay with that solution. 
Hopefully most would make use of it in high-level frameworks.

I guess similar to reflection and enabling dynamism. I look forward to 
eventually being able to do key-value-coding in pure Swift and being able to 
implement a framework similar to WebObjects which would require being able to 
find properties by their name, getting and setting values. That would be 
another example of opting in for a richer run-time. 


> On May 27, 2016, at 10:11 AM, Patrick Smith  wrote:
> 
> If you have to specify Equatable / Hashable, then you can get an error if the 
> automatic implementation failed, due to a member also not being 
> Equatable/Hashable. If it’s automatic, then it will just quietly fail, making 
> problems harder to know about and track. It will also always add to the 
> compile size, even if you didn’t want the functionality.
> 
> 
>> On 27 May 2016, at 10:46 PM, Ricardo Parada  wrote:
>> 
>> I agree, I think there is no need for deriving/synthesizes, but also, no 
>> need to specify Equatable, Hashable. They should get the functionality by 
>> default but allow for override and customization. 
>> 
>> 
>>> On May 26, 2016, at 11:02 PM, Patrick Smith  wrote:
>>> 
>>> I don’t understand why you couldn’t conform to Equatable, and if it fulfils 
>>> the requirements (all members are also Equatable), then its implementation 
>>> is automatically created for you. That way you don’t need a new keyword. 
>>> It’s like Objective-C’s property automatic synthesising that get used 
>>> unless you implement ones yourself.
>>> 
>>> 
 On 27 May 2016, at 12:57 PM, Ricardo Parada via swift-evolution 
  wrote:
 
 
 
 I wonder if synthesizes would be a better choice than deriving. 
 
 
 
> On May 26, 2016, at 5:58 AM, Michael Peternell via swift-evolution 
>  wrote:
> 
> Can we just copy the solution from Haskell instead of creating our 
> own? It's just better in every aspect. Deriving `Equatable` and 
> `Hashable` would become
> 
> struct Polygon deriving Equatable, Hashable {
>...
> }
> 
> This has several advantages:
> - you don't have to guess wether `Equatable` or `Hashable` should be 
> automatically derived or not.
> - Deriving becomes an explicit choice.
> - If you need a custom `Equatable` implementation (for whatever reason), 
> you can still do it.
> - It doesn't break any code that is unaware of the change
> - It can be extended in future versions of Swift, without introducing any 
> new incompatibilities. For example, `CustomStringConvertible` could be 
> derived just as easily.
> - It is compatible with generics. E.g. `struct Shape deriving 
> Equatable` will make every `Shape` equatable if `X` is equatable. But 
> if `X` is not equatable, `Shape` can be used as well. (Unless `X` is 
> not used, in which case every `Shape` would be equatable. Unless 
> something in the definition of `Shape` makes deriving `Equatable` 
> impossible => this produces an error.)
> - It is proven to work in production.
> 
> -Michael
> 
>> Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
>> :
>> 
>> Thanks so much for putting this together, Tony! Glad I was able to be 
>> some inspiration. :^)
>> 
>> 
>> On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
>>  wrote:
>> I was inspired to put together a draft proposal based on an older 
>> discussion in the Universal Equality, Hashability, and Comparability 
>> thread  
>> that recently got necromanced (thanks Mark Sands!).
>> 
>> I'm guessing that this would be a significant enough change that it's 
>> not possible for the Swift 3 timeline, but it's something that would 
>> benefit enough people that I want to make sure the discussion stays 
>> alive. If there are enough good feelings about it, I'll move it from my 
>> gist into an actual proposal PR.
>> 
>> Automatically deriving Equatable andHashable for value types
>> 
>>• Proposal: SE-
>>• Author(s): Tony Allevato
>>• Status: Awaiting review
>>• Review manager: TBD
>> Introduction
>> 
>> Value types are prevalent throughout the Swift language, and we 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Evan Maloney via swift-evolution]

I agree.

This also isn't the only case where a 'deriving' keyword would come in handy. 
I'm mulling a proposal for a compiler-derived enum, and I worried the 
magic-ness of it would face strong opposition. Having a 'deriving' keyword is 
the perfect solution, since it becomes explicit.



> On May 26, 2016, at 11:18 AM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> +1 to a `deriving` keyword
> 
> On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution 
> > wrote:
> Can we just copy the solution from Haskell instead of creating our own? 
> It's just better in every aspect. Deriving `Equatable` and `Hashable` would 
> become
> 
> struct Polygon deriving Equatable, Hashable {
> ...
> }
> 
> This has several advantages:
> - you don't have to guess wether `Equatable` or `Hashable` should be 
> automatically derived or not.
> - Deriving becomes an explicit choice.
> - If you need a custom `Equatable` implementation (for whatever reason), you 
> can still do it.
> - It doesn't break any code that is unaware of the change
> - It can be extended in future versions of Swift, without introducing any new 
> incompatibilities. For example, `CustomStringConvertible` could be derived 
> just as easily.
> - It is compatible with generics. E.g. `struct Shape deriving Equatable` 
> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
> equatable, `Shape` can be used as well. (Unless `X` is not used, in which 
> case every `Shape` would be equatable. Unless something in the definition 
> of `Shape` makes deriving `Equatable` impossible => this produces an error.)
> - It is proven to work in production.
> 
> -Michael
> 
> > Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
> > >:
> >
> > Thanks so much for putting this together, Tony! Glad I was able to be some 
> > inspiration. :^)
> >
> >
> > On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
> > > wrote:
> > I was inspired to put together a draft proposal based on an older 
> > discussion in the Universal Equality, Hashability, and Comparability thread 
> >  > > that 
> > recently got necromanced (thanks Mark Sands!).
> >
> > I'm guessing that this would be a significant enough change that it's not 
> > possible for the Swift 3 timeline, but it's something that would benefit 
> > enough people that I want to make sure the discussion stays alive. If there 
> > are enough good feelings about it, I'll move it from my gist into an actual 
> > proposal PR.
> >
> > Automatically deriving Equatable andHashable for value types
> >
> >   • Proposal: SE-
> >   • Author(s): Tony Allevato
> >   • Status: Awaiting review
> >   • Review manager: TBD
> > Introduction
> >
> > Value types are prevalent throughout the Swift language, and we encourage 
> > developers to think in those terms when writing their own types. 
> > Frequently, developers find themselves writing large amounts of boilerplate 
> > code to support equatability and hashability of value types. This proposal 
> > offers a way for the compiler to automatically derive conformance 
> > toEquatable and Hashable to reduce this boilerplate, in a subset of 
> > scenarios where generating the correct implementation is likely to be 
> > possible.
> >
> > Swift-evolution thread: Universal Equatability, Hashability, and 
> > Comparability
> >
> > Motivation
> >
> > Building robust value types in Swift can involve writing significant 
> > boilerplate code to support concepts of hashability and equatability. 
> > Equality is pervasive across many value types, and for each one users must 
> > implement the == operator such that it performs a fairly rote memberwise 
> > equality test. As an example, an equality test for a struct looks fairly 
> > uninteresting:
> >
> > func ==(lhs: Foo, rhs: Foo) -> Bool
> >  {
> >
> > return lhs.property1 == rhs.property1 &&
> >
> >  lhs
> > .property2 == rhs.property2 &&
> >
> >  lhs
> > .property3 == rhs.property3 &&
> >
> >
> > ...
> >
> > }
> >
> > What's worse is that this operator must be updated if any properties are 
> > added, removed, or changed, and since it must be manually written, it's 
> > possible to get it wrong, either by omission or typographical error.
> >
> > Likewise, hashability is necessary when one wishes to store a value type in 
> > a Set or use one as a multi-valuedDictionary key. Writing high-quality, 
> > well-distributed hash functions is not trivial so developers may not put a 
> > great deal of thought into them – especially as the number of properties 
> > increases – not realizing that their performance could potentially suffer 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Patrick Smith via swift-evolution]

If you have to specify Equatable / Hashable, then you can get an error if the 
automatic implementation failed, due to a member also not being 
Equatable/Hashable. If it’s automatic, then it will just quietly fail, making 
problems harder to know about and track. It will also always add to the compile 
size, even if you didn’t want the functionality.


> On 27 May 2016, at 10:46 PM, Ricardo Parada  wrote:
> 
> I agree, I think there is no need for deriving/synthesizes, but also, no need 
> to specify Equatable, Hashable. They should get the functionality by default 
> but allow for override and customization. 
> 
> 
> On May 26, 2016, at 11:02 PM, Patrick Smith  > wrote:
> 
>> I don’t understand why you couldn’t conform to Equatable, and if it fulfils 
>> the requirements (all members are also Equatable), then its implementation 
>> is automatically created for you. That way you don’t need a new keyword. 
>> It’s like Objective-C’s property automatic synthesising that get used unless 
>> you implement ones yourself.
>> 
>> 
>>> On 27 May 2016, at 12:57 PM, Ricardo Parada via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> 
>>> I wonder if synthesizes would be a better choice than deriving. 
>>> 
>>> 
>>> 
>>> On May 26, 2016, at 5:58 AM, Michael Peternell via swift-evolution 
>>> > wrote:
>>> 
 Can we just copy the solution from Haskell instead of creating our 
 own? It's just better in every aspect. Deriving `Equatable` and `Hashable` 
 would become
 
 struct Polygon deriving Equatable, Hashable {
...
 }
 
 This has several advantages:
 - you don't have to guess wether `Equatable` or `Hashable` should be 
 automatically derived or not.
 - Deriving becomes an explicit choice.
 - If you need a custom `Equatable` implementation (for whatever reason), 
 you can still do it.
 - It doesn't break any code that is unaware of the change
 - It can be extended in future versions of Swift, without introducing any 
 new incompatibilities. For example, `CustomStringConvertible` could be 
 derived just as easily.
 - It is compatible with generics. E.g. `struct Shape deriving 
 Equatable` will make every `Shape` equatable if `X` is equatable. But 
 if `X` is not equatable, `Shape` can be used as well. (Unless `X` is 
 not used, in which case every `Shape` would be equatable. Unless 
 something in the definition of `Shape` makes deriving `Equatable` 
 impossible => this produces an error.)
 - It is proven to work in production.
 
 -Michael
 
> Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
> >:
> 
> Thanks so much for putting this together, Tony! Glad I was able to be 
> some inspiration. :^)
> 
> 
> On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
> > wrote:
> I was inspired to put together a draft proposal based on an older 
> discussion in the Universal Equality, Hashability, and Comparability 
> thread  > that 
> recently got necromanced (thanks Mark Sands!).
> 
> I'm guessing that this would be a significant enough change that it's not 
> possible for the Swift 3 timeline, but it's something that would benefit 
> enough people that I want to make sure the discussion stays alive. If 
> there are enough good feelings about it, I'll move it from my gist into 
> an actual proposal PR.
> 
> Automatically deriving Equatable andHashable for value types
> 
>• Proposal: SE-
>• Author(s): Tony Allevato
>• Status: Awaiting review
>• Review manager: TBD
> Introduction
> 
> Value types are prevalent throughout the Swift language, and we encourage 
> developers to think in those terms when writing their own types. 
> Frequently, developers find themselves writing large amounts of 
> boilerplate code to support equatability and hashability of value types. 
> This proposal offers a way for the compiler to automatically derive 
> conformance toEquatable and Hashable to reduce this boilerplate, in a 
> subset of scenarios where generating the correct implementation is likely 
> to be possible.
> 
> Swift-evolution thread: Universal Equatability, Hashability, and 
> Comparability
> 
> Motivation
> 
> Building robust value types in Swift can involve writing significant 
> boilerplate code to support concepts of hashability and equatability. 
> Equality is 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Ricardo Parada via swift-evolution]

I agree, I think there is no need for deriving/synthesizes, but also, no need 
to specify Equatable, Hashable. They should get the functionality by default 
but allow for override and customization. 


> On May 26, 2016, at 11:02 PM, Patrick Smith  wrote:
> 
> I don’t understand why you couldn’t conform to Equatable, and if it fulfils 
> the requirements (all members are also Equatable), then its implementation is 
> automatically created for you. That way you don’t need a new keyword. It’s 
> like Objective-C’s property automatic synthesising that get used unless you 
> implement ones yourself.
> 
> 
>> On 27 May 2016, at 12:57 PM, Ricardo Parada via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> I wonder if synthesizes would be a better choice than deriving. 
>> 
>> 
>> 
>>> On May 26, 2016, at 5:58 AM, Michael Peternell via swift-evolution 
>>>  wrote:
>>> 
>>> Can we just copy the solution from Haskell instead of creating our 
>>> own? It's just better in every aspect. Deriving `Equatable` and `Hashable` 
>>> would become
>>> 
>>> struct Polygon deriving Equatable, Hashable {
>>>...
>>> }
>>> 
>>> This has several advantages:
>>> - you don't have to guess wether `Equatable` or `Hashable` should be 
>>> automatically derived or not.
>>> - Deriving becomes an explicit choice.
>>> - If you need a custom `Equatable` implementation (for whatever reason), 
>>> you can still do it.
>>> - It doesn't break any code that is unaware of the change
>>> - It can be extended in future versions of Swift, without introducing any 
>>> new incompatibilities. For example, `CustomStringConvertible` could be 
>>> derived just as easily.
>>> - It is compatible with generics. E.g. `struct Shape deriving Equatable` 
>>> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
>>> equatable, `Shape` can be used as well. (Unless `X` is not used, in 
>>> which case every `Shape` would be equatable. Unless something in the 
>>> definition of `Shape` makes deriving `Equatable` impossible => this 
>>> produces an error.)
>>> - It is proven to work in production.
>>> 
>>> -Michael
>>> 
 Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
 :
 
 Thanks so much for putting this together, Tony! Glad I was able to be some 
 inspiration. :^)
 
 
 On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
  wrote:
 I was inspired to put together a draft proposal based on an older 
 discussion in the Universal Equality, Hashability, and Comparability 
 thread  
 that recently got necromanced (thanks Mark Sands!).
 
 I'm guessing that this would be a significant enough change that it's not 
 possible for the Swift 3 timeline, but it's something that would benefit 
 enough people that I want to make sure the discussion stays alive. If 
 there are enough good feelings about it, I'll move it from my gist into an 
 actual proposal PR.
 
 Automatically deriving Equatable andHashable for value types
 
• Proposal: SE-
• Author(s): Tony Allevato
• Status: Awaiting review
• Review manager: TBD
 Introduction
 
 Value types are prevalent throughout the Swift language, and we encourage 
 developers to think in those terms when writing their own types. 
 Frequently, developers find themselves writing large amounts of 
 boilerplate code to support equatability and hashability of value types. 
 This proposal offers a way for the compiler to automatically derive 
 conformance toEquatable and Hashable to reduce this boilerplate, in a 
 subset of scenarios where generating the correct implementation is likely 
 to be possible.
 
 Swift-evolution thread: Universal Equatability, Hashability, and 
 Comparability
 
 Motivation
 
 Building robust value types in Swift can involve writing significant 
 boilerplate code to support concepts of hashability and equatability. 
 Equality is pervasive across many value types, and for each one users must 
 implement the == operator such that it performs a fairly rote memberwise 
 equality test. As an example, an equality test for a struct looks fairly 
 uninteresting:
 
 func ==(lhs: Foo, rhs: Foo) -> Bool
 {
 
 return lhs.property1 == rhs.property1 &&
 
 lhs
 .property2 == rhs.property2 &&
 
 lhs
 .property3 == rhs.property3 &&
 
 
 ...
 
 }
 
 What's worse is that this operator must be updated if any properties are 
 added, removed, or changed, and since it must be manually written, it's 
 possible to get it wrong, either by omission or typographical error.
 
 Likewise, hashability is 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On May 27, 2016, at 6:27 AM, David Sweeris via swift-evolution 
>  wrote:
> 
> +1 for "deriving", "synthesizes", or some other keyword. How are we going to 
> tell the compiler what protocols can participate? Something like 
> "@memberwise" is all I can think of, but I'm too tired for deep thought at 
> the moment.
> 
> - Dave Sweeris
> 
>> On May 26, 2016, at 21:57, Ricardo Parada via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> I wonder if synthesizes would be a better choice than deriving. 
>> 
>> 
>> 
>>> On May 26, 2016, at 5:58 AM, Michael Peternell via swift-evolution 
>>>  wrote:
>>> 
>>> Can we just copy the solution from Haskell instead of creating our 
>>> own? It's just better in every aspect. Deriving `Equatable` and `Hashable` 
>>> would become
>>> 
>>> struct Polygon deriving Equatable, Hashable {
>>>...
>>> }
>>> 

Can't make sense of the idea.
By vitue of being values, they de-facto carry the notion of something 
identifying them (basically their 'value'), makes them defacto 
hashable/equatable. Inventing a pseudo inheritance just so that what's already 
there can be restated makes no logical sense to me. So say we have invented 
this new (IMO highly contrived and redundant) syntax, it still does not address 
what most people will IMO wind-up asking for (just google around and you'll 
see): the ability to influence how the identity of their structs is composed.

So:
  -1 for deriving Equatable/Hashble

>>> This has several advantages:
>>> - you don't have to guess wether `Equatable` or `Hashable` should be 
>>> automatically derived or not.
>>> - Deriving becomes an explicit choice.
>>> - If you need a custom `Equatable` implementation (for whatever reason), 
>>> you can still do it.
>>> - It doesn't break any code that is unaware of the change
>>> - It can be extended in future versions of Swift, without introducing any 
>>> new incompatibilities. For example, `CustomStringConvertible` could be 
>>> derived just as easily.
>>> - It is compatible with generics. E.g. `struct Shape deriving Equatable` 
>>> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
>>> equatable, `Shape` can be used as well. (Unless `X` is not used, in 
>>> which case every `Shape` would be equatable. Unless something in the 
>>> definition of `Shape` makes deriving `Equatable` impossible => this 
>>> produces an error.)
>>> - It is proven to work in production.
>>> 
>>> -Michael
>>> 
 Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
 :
 
 Thanks so much for putting this together, Tony! Glad I was able to be some 
 inspiration. :^)
 
 
 On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
  wrote:
 I was inspired to put together a draft proposal based on an older 
 discussion in the Universal Equality, Hashability, and Comparability 
 thread  
 that recently got necromanced (thanks Mark Sands!).
 
 I'm guessing that this would be a significant enough change that it's not 
 possible for the Swift 3 timeline, but it's something that would benefit 
 enough people that I want to make sure the discussion stays alive. If 
 there are enough good feelings about it, I'll move it from my gist into an 
 actual proposal PR.
 
 Automatically deriving Equatable andHashable for value types
 
• Proposal: SE-
• Author(s): Tony Allevato
• Status: Awaiting review
• Review manager: TBD
 Introduction
 
 Value types are prevalent throughout the Swift language, and we encourage 
 developers to think in those terms when writing their own types. 
 Frequently, developers find themselves writing large amounts of 
 boilerplate code to support equatability and hashability of value types. 
 This proposal offers a way for the compiler to automatically derive 
 conformance toEquatable and Hashable to reduce this boilerplate, in a 
 subset of scenarios where generating the correct implementation is likely 
 to be possible.
 
 Swift-evolution thread: Universal Equatability, Hashability, and 
 Comparability
 
 Motivation
 
 Building robust value types in Swift can involve writing significant 
 boilerplate code to support concepts of hashability and equatability. 
 Equality is pervasive across many value types, and for each one users must 
 implement the == operator such that it performs a fairly rote memberwise 
 equality test. As an example, an equality test for a struct looks fairly 
 uninteresting:
 
 func ==(lhs: Foo, rhs: Foo) -> Bool
 {
 
 return lhs.property1 == rhs.property1 &&
 
 lhs
 .property2 == rhs.property2 &&
 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[David Sweeris via swift-evolution]

+1 for "deriving", "synthesizes", or some other keyword. How are we going to 
tell the compiler what protocols can participate? Something like "@memberwise" 
is all I can think of, but I'm too tired for deep thought at the moment.

- Dave Sweeris

> On May 26, 2016, at 21:57, Ricardo Parada via swift-evolution 
>  wrote:
> 
> 
> 
> I wonder if synthesizes would be a better choice than deriving. 
> 
> 
> 
>> On May 26, 2016, at 5:58 AM, Michael Peternell via swift-evolution 
>>  wrote:
>> 
>> Can we just copy the solution from Haskell instead of creating our 
>> own? It's just better in every aspect. Deriving `Equatable` and `Hashable` 
>> would become
>> 
>> struct Polygon deriving Equatable, Hashable {
>>...
>> }
>> 
>> This has several advantages:
>> - you don't have to guess wether `Equatable` or `Hashable` should be 
>> automatically derived or not.
>> - Deriving becomes an explicit choice.
>> - If you need a custom `Equatable` implementation (for whatever reason), you 
>> can still do it.
>> - It doesn't break any code that is unaware of the change
>> - It can be extended in future versions of Swift, without introducing any 
>> new incompatibilities. For example, `CustomStringConvertible` could be 
>> derived just as easily.
>> - It is compatible with generics. E.g. `struct Shape deriving Equatable` 
>> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
>> equatable, `Shape` can be used as well. (Unless `X` is not used, in which 
>> case every `Shape` would be equatable. Unless something in the definition 
>> of `Shape` makes deriving `Equatable` impossible => this produces an error.)
>> - It is proven to work in production.
>> 
>> -Michael
>> 
>>> Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
>>> :
>>> 
>>> Thanks so much for putting this together, Tony! Glad I was able to be some 
>>> inspiration. :^)
>>> 
>>> 
>>> On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
>>>  wrote:
>>> I was inspired to put together a draft proposal based on an older 
>>> discussion in the Universal Equality, Hashability, and Comparability thread 
>>>  that 
>>> recently got necromanced (thanks Mark Sands!).
>>> 
>>> I'm guessing that this would be a significant enough change that it's not 
>>> possible for the Swift 3 timeline, but it's something that would benefit 
>>> enough people that I want to make sure the discussion stays alive. If there 
>>> are enough good feelings about it, I'll move it from my gist into an actual 
>>> proposal PR.
>>> 
>>> Automatically deriving Equatable andHashable for value types
>>> 
>>>• Proposal: SE-
>>>• Author(s): Tony Allevato
>>>• Status: Awaiting review
>>>• Review manager: TBD
>>> Introduction
>>> 
>>> Value types are prevalent throughout the Swift language, and we encourage 
>>> developers to think in those terms when writing their own types. 
>>> Frequently, developers find themselves writing large amounts of boilerplate 
>>> code to support equatability and hashability of value types. This proposal 
>>> offers a way for the compiler to automatically derive conformance 
>>> toEquatable and Hashable to reduce this boilerplate, in a subset of 
>>> scenarios where generating the correct implementation is likely to be 
>>> possible.
>>> 
>>> Swift-evolution thread: Universal Equatability, Hashability, and 
>>> Comparability
>>> 
>>> Motivation
>>> 
>>> Building robust value types in Swift can involve writing significant 
>>> boilerplate code to support concepts of hashability and equatability. 
>>> Equality is pervasive across many value types, and for each one users must 
>>> implement the == operator such that it performs a fairly rote memberwise 
>>> equality test. As an example, an equality test for a struct looks fairly 
>>> uninteresting:
>>> 
>>> func ==(lhs: Foo, rhs: Foo) -> Bool
>>> {
>>> 
>>> return lhs.property1 == rhs.property1 &&
>>> 
>>> lhs
>>> .property2 == rhs.property2 &&
>>> 
>>> lhs
>>> .property3 == rhs.property3 &&
>>> 
>>> 
>>> ...
>>> 
>>> }
>>> 
>>> What's worse is that this operator must be updated if any properties are 
>>> added, removed, or changed, and since it must be manually written, it's 
>>> possible to get it wrong, either by omission or typographical error.
>>> 
>>> Likewise, hashability is necessary when one wishes to store a value type in 
>>> a Set or use one as a multi-valuedDictionary key. Writing high-quality, 
>>> well-distributed hash functions is not trivial so developers may not put a 
>>> great deal of thought into them – especially as the number of properties 
>>> increases – not realizing that their performance could potentially suffer 
>>> as a result. And as with equality, writing it manually means there is the 
>>> potential to get it wrong.
>>> 
>>> In particular, 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Ricardo Parada via swift-evolution]

As Steve Jobs once said when demoing Interface Builder during the NeXT days: 
"The line of code you don't have to write is the line of code you don't have to 
debug."

P.S. I hope I got the quote right, but that was the idea. :-)





Sent from my iPhone

> On May 25, 2016, at 10:02 PM, Patrick Smith via swift-evolution 
>  wrote:
> 
> This would be very handy! It’s one of those rare scenarios where I think “I 
> can’t believe Swift makes me type all this out, there must be an easier way”.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Ricardo Parada via swift-evolution]

I like this. 

I don't see why not make this the default. 

If someone thinks it is not needed for their application then they simply don't 
use it. Having it there would not cause any harm.  Unless someone had a 
requirement to have strict control on the size of the application and had to 
cut down on the amount of code. 

If we establish that value types get this by default then there is no need to 
make it explicit. It would become a known fact for value types in the Swift 
language. 

I don't see a reason to make this opt-in. I think there is more beneficial to 
make the behavior automatic and allow a way to override/ customize. 


> On May 25, 2016, at 2:28 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> I was inspired to put together a draft proposal based on an older discussion 
> in the Universal Equality, Hashability, and Comparability thread 
>  that recently 
> got necromanced (thanks Mark Sands!).
> 
> I'm guessing that this would be a significant enough change that it's not 
> possible for the Swift 3 timeline, but it's something that would benefit 
> enough people that I want to make sure the discussion stays alive. If there 
> are enough good feelings about it, I'll move it from my gist into an actual 
> proposal PR.
> 
> Automatically deriving Equatable andHashable for value types
> Proposal: SE-
> Author(s): Tony Allevato
> Status: Awaiting review
> Review manager: TBD
> Introduction
> 
> Value types are prevalent throughout the Swift language, and we encourage 
> developers to think in those terms when writing their own types. Frequently, 
> developers find themselves writing large amounts of boilerplate code to 
> support equatability and hashability of value types. This proposal offers a 
> way for the compiler to automatically derive conformance toEquatable and 
> Hashable to reduce this boilerplate, in a subset of scenarios where 
> generating the correct implementation is likely to be possible.
> 
> Swift-evolution thread: Universal Equatability, Hashability, and Comparability
> 
> Motivation
> 
> Building robust value types in Swift can involve writing significant 
> boilerplate code to support concepts of hashability and equatability. 
> Equality is pervasive across many value types, and for each one users must 
> implement the == operator such that it performs a fairly rote memberwise 
> equality test. As an example, an equality test for a struct looks fairly 
> uninteresting:
> 
> func ==(lhs: Foo, rhs: Foo) -> Bool {
>   return lhs.property1 == rhs.property1 &&
>  lhs.property2 == rhs.property2 &&
>  lhs.property3 == rhs.property3 &&
>  ...
> }
> What's worse is that this operator must be updated if any properties are 
> added, removed, or changed, and since it must be manually written, it's 
> possible to get it wrong, either by omission or typographical error.
> 
> Likewise, hashability is necessary when one wishes to store a value type in a 
> Set or use one as a multi-valuedDictionary key. Writing high-quality, 
> well-distributed hash functions is not trivial so developers may not put a 
> great deal of thought into them – especially as the number of properties 
> increases – not realizing that their performance could potentially suffer as 
> a result. And as with equality, writing it manually means there is the 
> potential to get it wrong.
> 
> In particular, the code that must be written to implement equality for enums 
> is quite verbose. One such real-world example (source):
> 
> func ==(lhs: HandRank, rhs: HandRank) -> Bool {
>   switch (lhs, rhs) {
>   case (.straightFlush(let lRank, let lSuit), .straightFlush(let rRank , let 
> rSuit)):
> return lRank == rRank && lSuit == rSuit
>   case (.fourOfAKind(four: let lFour), .fourOfAKind(four: let rFour)):
> return lFour == rFour
>   case (.fullHouse(three: let lThree), .fullHouse(three: let rThree)):
> return lThree == rThree
>   case (.flush(let lRank, let lSuit), .flush(let rRank, let rSuit)):
> return lSuit == rSuit && lRank == rRank
>   case (.straight(high: let lRank), .straight(high: let rRank)):
> return lRank == rRank
>   case (.threeOfAKind(three: let lRank), .threeOfAKind(three: let rRank)):
> return lRank == rRank
>   case (.twoPair(high: let lHigh, low: let lLow, highCard: let lCard),
> .twoPair(high: let rHigh, low: let rLow, highCard: let rCard)):
> return lHigh == rHigh && lLow == rLow && lCard == rCard
>   case (.onePair(let lPairRank, card1: let lCard1, card2: let lCard2, card3: 
> let lCard3),
> .onePair(let rPairRank, card1: let rCard1, card2: let rCard2, card3: 
> let rCard3)):
> return lPairRank == rPairRank && lCard1 == rCard1 && lCard2 == rCard2 && 
> lCard3 == rCard3
>   case (.highCard(let lCard), .highCard(let rCard)):
> return lCard == rCard
>   default:
> return false
>   }
> }
> Crafting a high-quality hash 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Patrick Smith via swift-evolution]

I don’t understand why you couldn’t conform to Equatable, and if it fulfils the 
requirements (all members are also Equatable), then its implementation is 
automatically created for you. That way you don’t need a new keyword. It’s like 
Objective-C’s property automatic synthesising that get used unless you 
implement ones yourself.


> On 27 May 2016, at 12:57 PM, Ricardo Parada via swift-evolution 
>  wrote:
> 
> 
> 
> I wonder if synthesizes would be a better choice than deriving. 
> 
> 
> 
> On May 26, 2016, at 5:58 AM, Michael Peternell via swift-evolution 
> > wrote:
> 
>> Can we just copy the solution from Haskell instead of creating our 
>> own? It's just better in every aspect. Deriving `Equatable` and `Hashable` 
>> would become
>> 
>> struct Polygon deriving Equatable, Hashable {
>>...
>> }
>> 
>> This has several advantages:
>> - you don't have to guess wether `Equatable` or `Hashable` should be 
>> automatically derived or not.
>> - Deriving becomes an explicit choice.
>> - If you need a custom `Equatable` implementation (for whatever reason), you 
>> can still do it.
>> - It doesn't break any code that is unaware of the change
>> - It can be extended in future versions of Swift, without introducing any 
>> new incompatibilities. For example, `CustomStringConvertible` could be 
>> derived just as easily.
>> - It is compatible with generics. E.g. `struct Shape deriving Equatable` 
>> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
>> equatable, `Shape` can be used as well. (Unless `X` is not used, in which 
>> case every `Shape` would be equatable. Unless something in the definition 
>> of `Shape` makes deriving `Equatable` impossible => this produces an error.)
>> - It is proven to work in production.
>> 
>> -Michael
>> 
>>> Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
>>> >:
>>> 
>>> Thanks so much for putting this together, Tony! Glad I was able to be some 
>>> inspiration. :^)
>>> 
>>> 
>>> On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
>>> > wrote:
>>> I was inspired to put together a draft proposal based on an older 
>>> discussion in the Universal Equality, Hashability, and Comparability thread 
>>> >> > that 
>>> recently got necromanced (thanks Mark Sands!).
>>> 
>>> I'm guessing that this would be a significant enough change that it's not 
>>> possible for the Swift 3 timeline, but it's something that would benefit 
>>> enough people that I want to make sure the discussion stays alive. If there 
>>> are enough good feelings about it, I'll move it from my gist into an actual 
>>> proposal PR.
>>> 
>>> Automatically deriving Equatable andHashable for value types
>>> 
>>>• Proposal: SE-
>>>• Author(s): Tony Allevato
>>>• Status: Awaiting review
>>>• Review manager: TBD
>>> Introduction
>>> 
>>> Value types are prevalent throughout the Swift language, and we encourage 
>>> developers to think in those terms when writing their own types. 
>>> Frequently, developers find themselves writing large amounts of boilerplate 
>>> code to support equatability and hashability of value types. This proposal 
>>> offers a way for the compiler to automatically derive conformance 
>>> toEquatable and Hashable to reduce this boilerplate, in a subset of 
>>> scenarios where generating the correct implementation is likely to be 
>>> possible.
>>> 
>>> Swift-evolution thread: Universal Equatability, Hashability, and 
>>> Comparability
>>> 
>>> Motivation
>>> 
>>> Building robust value types in Swift can involve writing significant 
>>> boilerplate code to support concepts of hashability and equatability. 
>>> Equality is pervasive across many value types, and for each one users must 
>>> implement the == operator such that it performs a fairly rote memberwise 
>>> equality test. As an example, an equality test for a struct looks fairly 
>>> uninteresting:
>>> 
>>> func ==(lhs: Foo, rhs: Foo) -> Bool
>>> {
>>> 
>>> return lhs.property1 == rhs.property1 &&
>>> 
>>> lhs
>>> .property2 == rhs.property2 &&
>>> 
>>> lhs
>>> .property3 == rhs.property3 &&
>>> 
>>> 
>>> ...
>>> 
>>> }
>>> 
>>> What's worse is that this operator must be updated if any properties are 
>>> added, removed, or changed, and since it must be manually written, it's 
>>> possible to get it wrong, either by omission or typographical error.
>>> 
>>> Likewise, hashability is necessary when one wishes to store a value type in 
>>> a Set or use one as a multi-valuedDictionary key. Writing high-quality, 
>>> well-distributed hash functions is not trivial so developers may not put a 
>>> great deal of thought into 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Ricardo Parada via swift-evolution]

I wonder if synthesizes would be a better choice than deriving. 



> On May 26, 2016, at 5:58 AM, Michael Peternell via swift-evolution 
>  wrote:
> 
> Can we just copy the solution from Haskell instead of creating our own? 
> It's just better in every aspect. Deriving `Equatable` and `Hashable` would 
> become
> 
> struct Polygon deriving Equatable, Hashable {
>...
> }
> 
> This has several advantages:
> - you don't have to guess wether `Equatable` or `Hashable` should be 
> automatically derived or not.
> - Deriving becomes an explicit choice.
> - If you need a custom `Equatable` implementation (for whatever reason), you 
> can still do it.
> - It doesn't break any code that is unaware of the change
> - It can be extended in future versions of Swift, without introducing any new 
> incompatibilities. For example, `CustomStringConvertible` could be derived 
> just as easily.
> - It is compatible with generics. E.g. `struct Shape deriving Equatable` 
> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
> equatable, `Shape` can be used as well. (Unless `X` is not used, in which 
> case every `Shape` would be equatable. Unless something in the definition 
> of `Shape` makes deriving `Equatable` impossible => this produces an error.)
> - It is proven to work in production.
> 
> -Michael
> 
>> Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
>> :
>> 
>> Thanks so much for putting this together, Tony! Glad I was able to be some 
>> inspiration. :^)
>> 
>> 
>> On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
>>  wrote:
>> I was inspired to put together a draft proposal based on an older discussion 
>> in the Universal Equality, Hashability, and Comparability thread 
>>  that 
>> recently got necromanced (thanks Mark Sands!).
>> 
>> I'm guessing that this would be a significant enough change that it's not 
>> possible for the Swift 3 timeline, but it's something that would benefit 
>> enough people that I want to make sure the discussion stays alive. If there 
>> are enough good feelings about it, I'll move it from my gist into an actual 
>> proposal PR.
>> 
>> Automatically deriving Equatable andHashable for value types
>> 
>>• Proposal: SE-
>>• Author(s): Tony Allevato
>>• Status: Awaiting review
>>• Review manager: TBD
>> Introduction
>> 
>> Value types are prevalent throughout the Swift language, and we encourage 
>> developers to think in those terms when writing their own types. Frequently, 
>> developers find themselves writing large amounts of boilerplate code to 
>> support equatability and hashability of value types. This proposal offers a 
>> way for the compiler to automatically derive conformance toEquatable and 
>> Hashable to reduce this boilerplate, in a subset of scenarios where 
>> generating the correct implementation is likely to be possible.
>> 
>> Swift-evolution thread: Universal Equatability, Hashability, and 
>> Comparability
>> 
>> Motivation
>> 
>> Building robust value types in Swift can involve writing significant 
>> boilerplate code to support concepts of hashability and equatability. 
>> Equality is pervasive across many value types, and for each one users must 
>> implement the == operator such that it performs a fairly rote memberwise 
>> equality test. As an example, an equality test for a struct looks fairly 
>> uninteresting:
>> 
>> func ==(lhs: Foo, rhs: Foo) -> Bool
>> {
>> 
>> return lhs.property1 == rhs.property1 &&
>> 
>> lhs
>> .property2 == rhs.property2 &&
>> 
>> lhs
>> .property3 == rhs.property3 &&
>> 
>> 
>> ...
>> 
>> }
>> 
>> What's worse is that this operator must be updated if any properties are 
>> added, removed, or changed, and since it must be manually written, it's 
>> possible to get it wrong, either by omission or typographical error.
>> 
>> Likewise, hashability is necessary when one wishes to store a value type in 
>> a Set or use one as a multi-valuedDictionary key. Writing high-quality, 
>> well-distributed hash functions is not trivial so developers may not put a 
>> great deal of thought into them – especially as the number of properties 
>> increases – not realizing that their performance could potentially suffer as 
>> a result. And as with equality, writing it manually means there is the 
>> potential to get it wrong.
>> 
>> In particular, the code that must be written to implement equality for enums 
>> is quite verbose. One such real-world example (source):
>> 
>> func ==(lhs: HandRank, rhs: HandRank) -> Bool
>> {
>> 
>> switch
>> (lhs, rhs) {
>> 
>> case (.straightFlush(let lRank, let lSuit), .straightFlush(let rRank , let
>> rSuit)):
>> 
>> return lRank == rRank && lSuit ==
>> rSuit
>> 
>> case (.fourOfAKind(four: let lFour), .fourOfAKind(four: let
>> rFour)):
>> 
>> return lFour ==
>> rFour
>> 
>> case 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Dave Abrahams via swift-evolution]

on Wed May 25 2016, Tony Allevato  wrote:

> I was inspired to put together a draft proposal based on an older discussion 
> in
> the Universal Equality, Hashability, and Comparability thread
>  that recently
> got necromanced (thanks Mark Sands!).
>
> I'm guessing that this would be a significant enough change that it's not
> possible for the Swift 3 timeline, but it's something that would benefit 
> enough
> people that I want to make sure the discussion stays alive. If there are 
> enough
> good feelings about it, I'll move it from my gist into an actual
> proposal PR.

Hi Tony,

As you might imagine I'm intensely interested in this topic and I have
some strongly held views.  That said, since it's out of scope for Swift
3, you shouldn't expect too much participation from me  at this point.

>
>
> Automatically deriving Equatable andHashable for value types
>
> * Proposal: SE-
> * Author(s): Tony Allevato
> * Status: Awaiting review
> * Review manager: TBD
>
> Introduction
>
> Value types are prevalent throughout the Swift language, and we encourage
> developers to think in those terms when writing their own types. Frequently,
> developers find themselves writing large amounts of boilerplate code to 
> support
> equatability and hashability of value types. This proposal offers a way for 
> the
> compiler to automatically derive conformance toEquatable and Hashable to 
> reduce
> this boilerplate, in a subset of scenarios where generating the correct
> implementation is likely to be possible.
>
> Swift-evolution thread: Universal Equatability, Hashability, and Comparability
>
> Motivation
>
> Building robust value types in Swift can involve writing significant 
> boilerplate
> code to support concepts of hashability and equatability. Equality is 
> pervasive
> across many value types, and for each one users must implement the == operator
> such that it performs a fairly rote memberwise equality test. As an example, 
> an
> equality test for a struct looks fairly uninteresting:
>
> func ==(lhs: Foo, rhs: Foo) -> Bool {
>   return lhs.property1 == rhs.property1 &&
>  lhs.property2 == rhs.property2 &&
>  lhs.property3 == rhs.property3 &&
>  ...
> }
>
> What's worse is that this operator must be updated if any properties are 
> added,
> removed, or changed, and since it must be manually written, it's possible to 
> get
> it wrong, either by omission or typographical error.
>
> Likewise, hashability is necessary when one wishes to store a value type in a
> Set or use one as a multi-valuedDictionary key. Writing high-quality,
> well-distributed hash functions is not trivial so developers may not put a 
> great
> deal of thought into them – especially as the number of properties increases –
> not realizing that their performance could potentially suffer as a result. And
> as with equality, writing it manually means there is the potential to get it
> wrong.
>
> In particular, the code that must be written to implement equality for enums 
> is
> quite verbose. One such real-world example (source):
>
> func ==(lhs: HandRank, rhs: HandRank) -> Bool {
>   switch (lhs, rhs) {
>   case (.straightFlush(let lRank, let lSuit), .straightFlush(let rRank , let 
> rSuit)):
> return lRank == rRank && lSuit == rSuit
>   case (.fourOfAKind(four: let lFour), .fourOfAKind(four: let rFour)):
> return lFour == rFour
>   case (.fullHouse(three: let lThree), .fullHouse(three: let rThree)):
> return lThree == rThree
>   case (.flush(let lRank, let lSuit), .flush(let rRank, let rSuit)):
> return lSuit == rSuit && lRank == rRank
>   case (.straight(high: let lRank), .straight(high: let rRank)):
> return lRank == rRank
>   case (.threeOfAKind(three: let lRank), .threeOfAKind(three: let rRank)):
> return lRank == rRank
>   case (.twoPair(high: let lHigh, low: let lLow, highCard: let lCard),
> .twoPair(high: let rHigh, low: let rLow, highCard: let rCard)):
> return lHigh == rHigh && lLow == rLow && lCard == rCard
>   case (.onePair(let lPairRank, card1: let lCard1, card2: let lCard2, card3: 
> let lCard3),
> .onePair(let rPairRank, card1: let rCard1, card2: let rCard2, card3: 
> let rCard3)):
> return lPairRank == rPairRank && lCard1 == rCard1 && lCard2 == rCard2 && 
> lCard3 == rCard3
>   case (.highCard(let lCard), .highCard(let rCard)):
> return lCard == rCard
>   default:
> return false
>   }
> }
>
> Crafting a high-quality hash function for this enum would be similarly
> inconvenient to write, involving another large switchstatement.
>
> Swift already provides implicit protocol conformance in some cases; notably,
> enums with raw values conform toRawRepresentable, Equatable, and Hashable
> without the user explicitly declaring them:
>
> enum Foo: Int {
>   case one = 1
>   case two = 2
> }
>
> let x = (Foo.one == Foo.two)  // works
> let y = Foo.one.hashValue 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[T.J. Usiyan via swift-evolution]

A `deriving` keyword, at the very least, is pretty explicitly *not* an
all-or-nothing situation. If you want to define equality/hashability for
your type manually, don't use `deriving`. This should leave the simplest
cases to auto generation and anything more complex should be handled by the
developer.

On Thu, May 26, 2016 at 11:20 AM, L. Mihalkovic <
laurent.mihalko...@gmail.com> wrote:

> what i care about is to have a choice about what DEFINES the identity of
> my values, not just an all-or-nothing situation.
>
> On May 26, 2016, at 5:18 PM, T.J. Usiyan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> +1 to a `deriving` keyword
>
> On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Can we just copy the solution from Haskell instead of creating our
>> own? It's just better in every aspect. Deriving `Equatable` and `Hashable`
>> would become
>>
>> struct Polygon deriving Equatable, Hashable {
>> ...
>> }
>>
>> This has several advantages:
>> - you don't have to guess wether `Equatable` or `Hashable` should be
>> automatically derived or not.
>> - Deriving becomes an explicit choice.
>> - If you need a custom `Equatable` implementation (for whatever reason),
>> you can still do it.
>> - It doesn't break any code that is unaware of the change
>> - It can be extended in future versions of Swift, without introducing any
>> new incompatibilities. For example, `CustomStringConvertible` could be
>> derived just as easily.
>> - It is compatible with generics. E.g. `struct Shape deriving
>> Equatable` will make every `Shape` equatable if `X` is equatable. But if
>> `X` is not equatable, `Shape` can be used as well. (Unless `X` is not
>> used, in which case every `Shape` would be equatable. Unless something
>> in the definition of `Shape` makes deriving `Equatable` impossible => this
>> produces an error.)
>> - It is proven to work in production.
>>
>> -Michael
>>
>> > Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution <
>> swift-evolution@swift.org>:
>> >
>> > Thanks so much for putting this together, Tony! Glad I was able to be
>> some inspiration. :^)
>> >
>> >
>> > On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> > I was inspired to put together a draft proposal based on an older
>> discussion in the Universal Equality, Hashability, and Comparability thread
>>  that
>> recently got necromanced (thanks Mark Sands!).
>> >
>> > I'm guessing that this would be a significant enough change that it's
>> not possible for the Swift 3 timeline, but it's something that would
>> benefit enough people that I want to make sure the discussion stays alive.
>> If there are enough good feelings about it, I'll move it from my gist into
>> an actual proposal PR.
>> >
>> > Automatically deriving Equatable andHashable for value types
>> >
>> >   • Proposal: SE-
>> >   • Author(s): Tony Allevato
>> >   • Status: Awaiting review
>> >   • Review manager: TBD
>> > Introduction
>> >
>> > Value types are prevalent throughout the Swift language, and we
>> encourage developers to think in those terms when writing their own types.
>> Frequently, developers find themselves writing large amounts of boilerplate
>> code to support equatability and hashability of value types. This proposal
>> offers a way for the compiler to automatically derive conformance
>> toEquatable and Hashable to reduce this boilerplate, in a subset of
>> scenarios where generating the correct implementation is likely to be
>> possible.
>> >
>> > Swift-evolution thread: Universal Equatability, Hashability, and
>> Comparability
>> >
>> > Motivation
>> >
>> > Building robust value types in Swift can involve writing significant
>> boilerplate code to support concepts of hashability and equatability.
>> Equality is pervasive across many value types, and for each one users must
>> implement the == operator such that it performs a fairly rote memberwise
>> equality test. As an example, an equality test for a struct looks fairly
>> uninteresting:
>> >
>> > func ==(lhs: Foo, rhs: Foo) -> Bool
>> >  {
>> >
>> > return lhs.property1 == rhs.property1 &&
>> >
>> >  lhs
>> > .property2 == rhs.property2 &&
>> >
>> >  lhs
>> > .property3 == rhs.property3 &&
>> >
>> >
>> > ...
>> >
>> > }
>> >
>> > What's worse is that this operator must be updated if any properties
>> are added, removed, or changed, and since it must be manually written, it's
>> possible to get it wrong, either by omission or typographical error.
>> >
>> > Likewise, hashability is necessary when one wishes to store a value
>> type in a Set or use one as a multi-valuedDictionary key. Writing
>> high-quality, well-distributed hash functions is not trivial so developers
>> may not put a great deal of thought into them – especially as the number of
>> properties increases – 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Michael Peternell via swift-evolution]

> Am 26.05.2016 um 17:35 schrieb Matthew Johnson :
> 
> 
>> On May 26, 2016, at 10:18 AM, T.J. Usiyan via swift-evolution 
>>  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 deriving Equatable` 
>> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
>> equatable, `Shape` can be used as well. 
> 
> You should not be able to just say `struct Shape 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 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Matthew Johnson via swift-evolution]

> On May 26, 2016, at 10:18 AM, T.J. Usiyan via swift-evolution 
>  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 deriving Equatable` 
> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
> equatable, `Shape` can be used as well. 


You should not be able to just say `struct Shape 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.

> 
> On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution 
> > wrote:
> Can we just copy the solution from Haskell instead of creating our own? 
> It's just better in every aspect. Deriving `Equatable` and `Hashable` would 
> become
> 
> struct Polygon deriving Equatable, Hashable {
> ...
> }
> 
> This has several advantages:
> - you don't have to guess wether `Equatable` or `Hashable` should be 
> automatically derived or not.
> - Deriving becomes an explicit choice.
> - If you need a custom `Equatable` implementation (for whatever reason), you 
> can still do it.
> - It doesn't break any code that is unaware of the change
> - It can be extended in future versions of Swift, without introducing any new 
> incompatibilities. For example, `CustomStringConvertible` could be derived 
> just as easily.
> - It is compatible with generics. E.g. `struct Shape deriving Equatable` 
> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
> equatable, `Shape` can be used as well. (Unless `X` is not used, in which 
> case every `Shape` would be equatable. Unless something in the definition 
> of `Shape` makes deriving `Equatable` impossible => this produces an error.)
> - It is proven to work in production.
> 
> -Michael
> 
> > Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
> > >:
> >
> > Thanks so much for putting this together, Tony! Glad I was able to be some 
> > inspiration. :^)
> >
> >
> > On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
> > > wrote:
> > I was inspired to put together a draft proposal based on an older 
> > discussion in the Universal Equality, Hashability, and Comparability thread 
> >  > > that 
> > recently got necromanced (thanks Mark Sands!).
> >
> > I'm guessing that this would be a significant enough change that it's not 
> > possible for the Swift 3 timeline, but it's something that would benefit 
> > enough people that I want to make sure the discussion stays alive. If there 
> > are enough good feelings about it, I'll move it from my gist into an actual 
> > proposal PR.
> >
> > Automatically deriving Equatable andHashable for value types
> >
> >   • Proposal: SE-
> >   • Author(s): Tony Allevato
> >   • Status: Awaiting review
> >   • Review manager: TBD
> > Introduction
> >
> > Value types are prevalent throughout the Swift language, and we encourage 
> > developers to think in those terms when writing their own types. 
> > Frequently, developers find themselves writing large amounts of boilerplate 
> > code to support equatability and hashability of value types. This proposal 
> > offers a way for the compiler to automatically derive conformance 
> > toEquatable and Hashable to reduce this boilerplate, in a subset of 
> > scenarios where generating the correct implementation is likely to be 
> > possible.
> >
> > Swift-evolution thread: Universal Equatability, Hashability, and 
> > Comparability
> >
> > Motivation
> >
> > Building robust value types in Swift can involve writing significant 
> > boilerplate code to support concepts of hashability and equatability. 
> > Equality is pervasive across many value types, and for each one users must 
> > implement the == operator such that it performs a fairly rote memberwise 
> > equality test. As an example, an equality test for a struct looks fairly 
> > uninteresting:
> >
> > func ==(lhs: Foo, rhs: Foo) -> Bool
> >  {
> >
> > return lhs.property1 == rhs.property1 &&
> >
> >  lhs
> > .property2 == rhs.property2 &&
> >
> >  lhs
> > .property3 == rhs.property3 &&
> >
> >
> > ...
> >
> > }
> >
> > What's worse is that this operator 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[T.J. Usiyan via swift-evolution]

+1 to a `deriving` keyword

On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution <
swift-evolution@swift.org> wrote:

> Can we just copy the solution from Haskell instead of creating our
> own? It's just better in every aspect. Deriving `Equatable` and `Hashable`
> would become
>
> struct Polygon deriving Equatable, Hashable {
> ...
> }
>
> This has several advantages:
> - you don't have to guess wether `Equatable` or `Hashable` should be
> automatically derived or not.
> - Deriving becomes an explicit choice.
> - If you need a custom `Equatable` implementation (for whatever reason),
> you can still do it.
> - It doesn't break any code that is unaware of the change
> - It can be extended in future versions of Swift, without introducing any
> new incompatibilities. For example, `CustomStringConvertible` could be
> derived just as easily.
> - It is compatible with generics. E.g. `struct Shape deriving
> Equatable` will make every `Shape` equatable if `X` is equatable. But if
> `X` is not equatable, `Shape` can be used as well. (Unless `X` is not
> used, in which case every `Shape` would be equatable. Unless something
> in the definition of `Shape` makes deriving `Equatable` impossible => this
> produces an error.)
> - It is proven to work in production.
>
> -Michael
>
> > Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution <
> swift-evolution@swift.org>:
> >
> > Thanks so much for putting this together, Tony! Glad I was able to be
> some inspiration. :^)
> >
> >
> > On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
> > I was inspired to put together a draft proposal based on an older
> discussion in the Universal Equality, Hashability, and Comparability thread
>  that
> recently got necromanced (thanks Mark Sands!).
> >
> > I'm guessing that this would be a significant enough change that it's
> not possible for the Swift 3 timeline, but it's something that would
> benefit enough people that I want to make sure the discussion stays alive.
> If there are enough good feelings about it, I'll move it from my gist into
> an actual proposal PR.
> >
> > Automatically deriving Equatable andHashable for value types
> >
> >   • Proposal: SE-
> >   • Author(s): Tony Allevato
> >   • Status: Awaiting review
> >   • Review manager: TBD
> > Introduction
> >
> > Value types are prevalent throughout the Swift language, and we
> encourage developers to think in those terms when writing their own types.
> Frequently, developers find themselves writing large amounts of boilerplate
> code to support equatability and hashability of value types. This proposal
> offers a way for the compiler to automatically derive conformance
> toEquatable and Hashable to reduce this boilerplate, in a subset of
> scenarios where generating the correct implementation is likely to be
> possible.
> >
> > Swift-evolution thread: Universal Equatability, Hashability, and
> Comparability
> >
> > Motivation
> >
> > Building robust value types in Swift can involve writing significant
> boilerplate code to support concepts of hashability and equatability.
> Equality is pervasive across many value types, and for each one users must
> implement the == operator such that it performs a fairly rote memberwise
> equality test. As an example, an equality test for a struct looks fairly
> uninteresting:
> >
> > func ==(lhs: Foo, rhs: Foo) -> Bool
> >  {
> >
> > return lhs.property1 == rhs.property1 &&
> >
> >  lhs
> > .property2 == rhs.property2 &&
> >
> >  lhs
> > .property3 == rhs.property3 &&
> >
> >
> > ...
> >
> > }
> >
> > What's worse is that this operator must be updated if any properties are
> added, removed, or changed, and since it must be manually written, it's
> possible to get it wrong, either by omission or typographical error.
> >
> > Likewise, hashability is necessary when one wishes to store a value type
> in a Set or use one as a multi-valuedDictionary key. Writing high-quality,
> well-distributed hash functions is not trivial so developers may not put a
> great deal of thought into them – especially as the number of properties
> increases – not realizing that their performance could potentially suffer
> as a result. And as with equality, writing it manually means there is the
> potential to get it wrong.
> >
> > In particular, the code that must be written to implement equality for
> enums is quite verbose. One such real-world example (source):
> >
> > func ==(lhs: HandRank, rhs: HandRank) -> Bool
> >  {
> >
> > switch
> >  (lhs, rhs) {
> >
> > case (.straightFlush(let lRank, let lSuit), .straightFlush(let rRank ,
> let
> >  rSuit)):
> >
> > return lRank == rRank && lSuit ==
> >  rSuit
> >
> > case (.fourOfAKind(four: let lFour), .fourOfAKind(four: let
> >  rFour)):
> >
> > return lFour ==
> >  rFour
> >
> > case (.fullHouse(three: let lThree), .fullHouse(three: 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Michael Peternell via swift-evolution]

Can we just copy the solution from Haskell instead of creating our own? 
It's just better in every aspect. Deriving `Equatable` and `Hashable` would 
become

struct Polygon deriving Equatable, Hashable {
...
}

This has several advantages:
- you don't have to guess wether `Equatable` or `Hashable` should be 
automatically derived or not.
- Deriving becomes an explicit choice.
- If you need a custom `Equatable` implementation (for whatever reason), you 
can still do it.
- It doesn't break any code that is unaware of the change
- It can be extended in future versions of Swift, without introducing any new 
incompatibilities. For example, `CustomStringConvertible` could be derived just 
as easily.
- It is compatible with generics. E.g. `struct Shape deriving Equatable` 
will make every `Shape` equatable if `X` is equatable. But if `X` is not 
equatable, `Shape` can be used as well. (Unless `X` is not used, in which 
case every `Shape` would be equatable. Unless something in the definition of 
`Shape` makes deriving `Equatable` impossible => this produces an error.)
- It is proven to work in production.

-Michael

> Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
> :
> 
> Thanks so much for putting this together, Tony! Glad I was able to be some 
> inspiration. :^)
> 
> 
> On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
>  wrote:
> I was inspired to put together a draft proposal based on an older discussion 
> in the Universal Equality, Hashability, and Comparability thread 
>  that recently 
> got necromanced (thanks Mark Sands!).
> 
> I'm guessing that this would be a significant enough change that it's not 
> possible for the Swift 3 timeline, but it's something that would benefit 
> enough people that I want to make sure the discussion stays alive. If there 
> are enough good feelings about it, I'll move it from my gist into an actual 
> proposal PR.
> 
> Automatically deriving Equatable andHashable for value types
> 
>   • Proposal: SE-
>   • Author(s): Tony Allevato
>   • Status: Awaiting review
>   • Review manager: TBD
> Introduction
> 
> Value types are prevalent throughout the Swift language, and we encourage 
> developers to think in those terms when writing their own types. Frequently, 
> developers find themselves writing large amounts of boilerplate code to 
> support equatability and hashability of value types. This proposal offers a 
> way for the compiler to automatically derive conformance toEquatable and 
> Hashable to reduce this boilerplate, in a subset of scenarios where 
> generating the correct implementation is likely to be possible.
> 
> Swift-evolution thread: Universal Equatability, Hashability, and Comparability
> 
> Motivation
> 
> Building robust value types in Swift can involve writing significant 
> boilerplate code to support concepts of hashability and equatability. 
> Equality is pervasive across many value types, and for each one users must 
> implement the == operator such that it performs a fairly rote memberwise 
> equality test. As an example, an equality test for a struct looks fairly 
> uninteresting:
> 
> func ==(lhs: Foo, rhs: Foo) -> Bool
>  {
>   
> return lhs.property1 == rhs.property1 &&
> 
>  lhs
> .property2 == rhs.property2 &&
> 
>  lhs
> .property3 == rhs.property3 &&
> 
>  
> ...
> 
> }
> 
> What's worse is that this operator must be updated if any properties are 
> added, removed, or changed, and since it must be manually written, it's 
> possible to get it wrong, either by omission or typographical error.
> 
> Likewise, hashability is necessary when one wishes to store a value type in a 
> Set or use one as a multi-valuedDictionary key. Writing high-quality, 
> well-distributed hash functions is not trivial so developers may not put a 
> great deal of thought into them – especially as the number of properties 
> increases – not realizing that their performance could potentially suffer as 
> a result. And as with equality, writing it manually means there is the 
> potential to get it wrong.
> 
> In particular, the code that must be written to implement equality for enums 
> is quite verbose. One such real-world example (source):
> 
> func ==(lhs: HandRank, rhs: HandRank) -> Bool
>  {
>   
> switch
>  (lhs, rhs) {
>   
> case (.straightFlush(let lRank, let lSuit), .straightFlush(let rRank , let
>  rSuit)):
> 
> return lRank == rRank && lSuit ==
>  rSuit
>   
> case (.fourOfAKind(four: let lFour), .fourOfAKind(four: let
>  rFour)):
> 
> return lFour ==
>  rFour
>   
> case (.fullHouse(three: let lThree), .fullHouse(three: let
>  rThree)):
> 
> return lThree ==
>  rThree
>   
> case (.flush(let lRank, let lSuit), .flush(let rRank, let
>  rSuit)):
> 
> return lSuit == rSuit && lRank ==
>  rRank
>   
> case (.straight(high: let lRank), 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[L. Mihalkovic via swift-evolution]

On May 26, 2016, at 3:08 AM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> Omission of fields from generated computations
>> 
>> Should it be possible to easily omit certain properties from automatically 
>> generated equality tests or hash value computation? This could be valuable, 
>> for example, if a property is merely used as an internal cache and does not 
>> actually contribute to the "value" of the instance. Under the rules above, 
>> if this cached value was equatable, a user would have to override == and 
>> hashValue and provide their own implementations to ignore it. If there is 
>> significant evidence that this pattern is common and useful, we could 
>> consider adding a custom attribute, such as @transient, that would omit the 
>> property from the generated computations.
> 
> A word of warning: an earlier proposal on memberwise initializers ran aground 
> because it tried to annotate properties to tell the compiler which ones 
> should be included in the generated initializer. It was ultimately judged too 
> complex a solution for the specialized problem space it was trying to tackle.
> 

Can't fathom how one would not see the difference in complexity between the 
initializer proposals (untainable as they were proposed) and how simple it is 
to discriminate during generation of identity. Not to mention the other reasons 
why initializer generation could be turned down.

> In other words, Keep It Simple, Stupid. 
> 
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Patrick Smith via swift-evolution]

This would be very handy! It’s one of those rare scenarios where I think “I 
can’t believe Swift makes me type all this out, there must be an easier way”.

I think explicitly conformance to Equatable and Hashable would be preferable. 
This means if one of the members is not Equable/Hashable, the user knows by 
getting an error of ‘Does not conform to Equatable, must implement func ==’ at 
the type level rather than scratching their head when instances are not 
automatically Equatable. It also means code is only generated when it is needed.

There’s a small typo (before [sic] below):

> On 26 May 2016, at 4:28 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
> As with raw-value enums today, should the derived conformance be completely 
> explicit [sic], or should users have to explicitly list conformance with 
> Equatable and Hashable in order for the compiler to generate the derived 
> implementation?

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Mark Sands via swift-evolution]

Thanks so much for putting this together, Tony! Glad I was able to be some
inspiration. :^)


On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution <
swift-evolution@swift.org> wrote:

> I was inspired to put together a draft proposal based on an older
> discussion in the Universal Equality, Hashability, and Comparability thread
>  that
> recently got necromanced (thanks Mark Sands!).
>
> I'm guessing that this would be a significant enough change that it's not
> possible for the Swift 3 timeline, but it's something that would benefit
> enough people that I want to make sure the discussion stays alive. If there
> are enough good feelings about it, I'll move it from my gist into an actual
> proposal PR.
>
> Automatically deriving Equatable andHashable for value types
>
>- Proposal: SE-
>
> 
>- Author(s): Tony Allevato 
>- Status: Awaiting review
>
> 
>- Review manager: TBD
>
>
> 
> Introduction
>
> Value types are prevalent throughout the Swift language, and we encourage
> developers to think in those terms when writing their own types.
> Frequently, developers find themselves writing large amounts of boilerplate
> code to support equatability and hashability of value types. This proposal
> offers a way for the compiler to automatically derive conformance to
> Equatable and Hashable to reduce this boilerplate, in a subset of
> scenarios where generating the correct implementation is likely to be
> possible.
>
> Swift-evolution thread: Universal Equatability, Hashability, and
> Comparability
> 
>
> 
> Motivation
>
> Building robust value types in Swift can involve writing significant
> boilerplate code to support concepts of hashability and equatability.
> Equality is pervasive across many value types, and for each one users must
> implement the == operator such that it performs a fairly rote memberwise
> equality test. As an example, an equality test for a struct looks fairly
> uninteresting:
>
> func ==(lhs: Foo, rhs: Foo) -> Bool {
>   return lhs.property1 == rhs.property1 &&
>  lhs.property2 == rhs.property2 &&
>  lhs.property3 == rhs.property3 &&
>  ...
> }
>
> What's worse is that this operator must be updated if any properties are
> added, removed, or changed, and since it must be manually written, it's
> possible to get it wrong, either by omission or typographical error.
>
> Likewise, hashability is necessary when one wishes to store a value type
> in a Set or use one as a multi-valuedDictionary key. Writing
> high-quality, well-distributed hash functions is not trivial so developers
> may not put a great deal of thought into them – especially as the number of
> properties increases – not realizing that their performance could
> potentially suffer as a result. And as with equality, writing it manually
> means there is the potential to get it wrong.
>
> In particular, the code that must be written to implement equality for
> enums is quite verbose. One such real-world example (source
> 
> ):
>
> func ==(lhs: HandRank, rhs: HandRank) -> Bool {
>   switch (lhs, rhs) {
>   case (.straightFlush(let lRank, let lSuit), .straightFlush(let rRank , let 
> rSuit)):
> return lRank == rRank && lSuit == rSuit
>   case (.fourOfAKind(four: let lFour), .fourOfAKind(four: let rFour)):
> return lFour == rFour
>   case (.fullHouse(three: let lThree), .fullHouse(three: let rThree)):
> return lThree == rThree
>   case (.flush(let lRank, let lSuit), .flush(let rRank, let rSuit)):
> return lSuit == rSuit && lRank == rRank
>   case (.straight(high: let lRank), .straight(high: let rRank)):
> return lRank == rRank
>   case (.threeOfAKind(three: let lRank), .threeOfAKind(three: let rRank)):
> return lRank == rRank
>   case (.twoPair(high: let lHigh, low: let lLow, highCard: let lCard),
> .twoPair(high: let rHigh, low: let rLow, highCard: let rCard)):
> return lHigh == rHigh && lLow == rLow && lCard == rCard
>   case (.onePair(let lPairRank, card1: let lCard1, card2: let lCard2, card3: 
> let lCard3),
> .onePair(let rPairRank, card1: let rCard1, card2: let rCard2, card3: 
> let rCard3)):
> return lPairRank == rPairRank && lCard1 == rCard1 && lCard2 == rCard2 && 
> lCard3 == rCard3
>   case (.highCard(let lCard), .highCard(let rCard)):
> return lCard == rCard
>   default:
> return false
>   }
> }
>
> Crafting a high-quality hash function for this enum would be 

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Matthew Johnson via swift-evolution]

Sent from my iPad

On May 25, 2016, at 8:08 PM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> Omission of fields from generated computations
>> 
>> Should it be possible to easily omit certain properties from automatically 
>> generated equality tests or hash value computation? This could be valuable, 
>> for example, if a property is merely used as an internal cache and does not 
>> actually contribute to the "value" of the instance. Under the rules above, 
>> if this cached value was equatable, a user would have to override == and 
>> hashValue and provide their own implementations to ignore it. If there is 
>> significant evidence that this pattern is common and useful, we could 
>> consider adding a custom attribute, such as @transient, that would omit the 
>> property from the generated computations.
> 
> A word of warning: an earlier proposal on memberwise initializers ran aground 
> because it tried to annotate properties to tell the compiler which ones 
> should be included in the generated initializer. It was ultimately judged too 
> complex a solution for the specialized problem space it was trying to tackle.

That's not entirely true.  The solution the core team was leaning towards in 
their feedback also included property annotations.  The proposal was deferred 
because a lot of new ideas were discussed during the review period and our 
understanding of the design space was refined.  By the end of the review not 
even I was convinced that the proposal as written was the right long term 
solution.

If we're going to derive automatic Equatable and Hashable implementations it is 
necessary to exclude certain members.  We can talk about strategies for doing 
that, and possibly for minimizing cases where the annotations are used, but we 
need some kind of control.  

The common case where annotations will be required is likely to be for a small 
number of members relative to those contributing to Equatable and Hashable.  An 
annotation or two are much better than writing out manual implementations.  
They also scale nicely if we are able to derive implementations of other 
protocols in the future.

> 
> In other words, Keep It Simple, Stupid. 
> 
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

[Brent Royal-Gordon via swift-evolution]

> Omission of fields from generated computations
> 
> Should it be possible to easily omit certain properties from automatically 
> generated equality tests or hash value computation? This could be valuable, 
> for example, if a property is merely used as an internal cache and does not 
> actually contribute to the "value" of the instance. Under the rules above, if 
> this cached value was equatable, a user would have to override == and 
> hashValue and provide their own implementations to ignore it. If there is 
> significant evidence that this pattern is common and useful, we could 
> consider adding a custom attribute, such as @transient, that would omit the 
> property from the generated computations.

A word of warning: an earlier proposal on memberwise initializers ran aground 
because it tried to annotate properties to tell the compiler which ones should 
be included in the generated initializer. It was ultimately judged too complex 
a solution for the specialized problem space it was trying to tackle.

In other words, Keep It Simple, Stupid. 


-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution