[swift-evolution] Auto-generate op==?

Dany St-Amant dsa.mls at icloud.com
Sat Feb 13 19:11:14 CST 2016


> Le 13 févr. 2016 à 15:54, Daniel T. via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> Yes, that's exactly what I am suggesting. Maybe even do the same for Hashable. (And any other protocol where there is an obvious implementation...)
> 
> As for syntax, I don't much care. A "deriving" keyword could be added, or maybe if you mark the type as Equatable and don't provide an implantation, it would auto-generate one for you, or error out.

For safety the programmer must opt-in via a keyword like this ‘deriving’, as an implicit auto-generated implementation may not give the proper result.

struct fraction {
    var numerator: Int
    var denominator: Int
}

An auto-generared implementation will say that 1/2 and 3/6 are different, while a properly implemented Equatable function will report equality.

Dany

> I personally feel that most value types should be equatable, but I tend not to do it purely because of all the boilerplate required. This sort of mechanism would help tremendously. 
> 
> I don't see any reason to limit such an idea to just value types, but that is where it's most  needed IMHO.
> 
> Based on an earlier comment, this type of feature would probably have to wait until 3.0, but I wanted to put the idea out there.
> 
> 
> Sent from my iPad
> 
> On Feb 13, 2016, at 12:38 PM, Donald Pinckney <djpinckney at ucdavis.edu <mailto:djpinckney at ucdavis.edu>> wrote:
> 
>> To make sure I understand correctly, what you are discussing is having == be auto generated in some way for types. The automatic implementation of == would be a member wise logical and operation:
>> 
>> struct Person {
>>    let age: Int
>>    let name: String
>> } deriving Equatable
>> 
>> Would also generate:
>> func ==(left: Person, right: Person) -> Bool {
>>    return left.age == right.age && left.name == right.name;
>> }
>> 
>> The compiler would only do this if all data members implement (or derive) the Equatable protocol, and probably error otherwise.
>> 
>> That's my interpretation.  If I misunderstood, please correct me.  
>> 
>> As it stands, I think something like this is a fabulous idea, as I have recently found myself writing lots of member wise equality checks.
>> 
>> Donald Pinckney
>> 
>> Sent from my iPhone
>> 
>> On Feb 13, 2016, at 9:12 AM, Donnacha Oisín Kidney via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> In Haskell, when you declare a datatype, you can follow it with a “deriving” clause, and it will derive several typeclasses (which are Haskell’s equivalent to protocols):
>>> 
>>> data Person = Person { name :: String, age :: Int } deriving Eq
>>> 
>>> In Swift, I’d imaging the equivalent would be something like:
>>> 
>>> struct Person {
>>>   let name: String
>>>   let age: Int
>>> } deriving Equatable
>>> 
>>>> On 13 Feb 2016, at 17:04, Patrick Gili via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> Not having a lot of experience with Haskell, can you provide an example, so that we can better understand what you're proposing?
>>>> 
>>>> Cheers,
>>>> -Patrick
>>>> 
>>>>> On Feb 12, 2016, at 3:47 PM, Daniel Tartaglia via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> In Haskell, we can mark a data block as deriving from Eq and it will auto-generate the == operator.
>>>>> 
>>>>> I would like to see Swift auto-generate the == operator if a struct implements Equatable. Obviously, it would only be able to do this if all the structs members implemented Equatable themselves.
>>>>> 
>>>>> Has this idea already been proposed? I didn’t see it at the github repo…
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160213/7b510c3f/attachment.html>


More information about the swift-evolution mailing list