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

danielt1263 at gmail.com danielt1263 at gmail.com
Sat Feb 13 21:44:07 CST 2016


I don't think all that is necessary. If you don't like the default implementation for some reason, just implement it yourself. The point of this idea is to make the common case easy.

If the system you are talking about was in place, readers couldn't trust the derived implementation without first examining the entire definition. Your additions would also discourage adding other derived methods in the future. One set of annotations for Equatable, another set for Hashable, another set for DebugPrintable... Such a system would be unwieldy to say the least.

Sent from my iPad

> On Feb 13, 2016, at 6:43 PM, Haravikk <swift-evolution at haravikk.me> wrote:
> 
> I discussed this recently,  there are two things that might be worth considering at the same time:
> 
> There should probably be an attribute so that we can indicate properties that should not be compared. This would also be a useful way to tell the compiler to ignore non-equatable values if we don’t actually care about them in the comparison.
> It might be nice now or in future if we could also build upon the auto-generated implementation. For example, by marking properties as ignored like I say, we could then add custom code for these while still letting the compiler auto-generate the simpler cases for us.
> 
>> On 13 Feb 2016, at 22:32, Patrick Gili via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Agreed.
>> 
>> In the property behaviors review, Chris Lattner mentioned that there is a trend to use # to denote compiler synthesis. Thus, this is probably a good alternative.
>> 
>> Cheers,
>> -Patrick
>> 
>>> On Feb 13, 2016, at 4:37 PM, Developer <devteam.codafi at gmail.com> wrote:
>>> 
>>> I'd be in favor of forgoing the keyword addition and just prefixing compiler-derivable protocols with a # or @.  Save `deriving` for later extensions to a future generalized deriving mechanism.
>>> 
>>> ~Robert Widmann
>>> 
>>> 2016/02/13 16:29、Patrick Gili via swift-evolution <swift-evolution at swift.org> のメッセージ:
>>> 
>>>> I've been playing with the concept in Haskell, and I like the concept. However, I don't like the proposed syntax, as it is not consistent the rest of the language. Maybe something like
>>>> 
>>>> struct Person : deriving Equatable {
>>>>     let age: Int
>>>>     let name: String
>>>> }
>>>> 
>>>> or 
>>>> 
>>>> struct Person : @deriving Equatable {
>>>>     let age: Int
>>>>     let name: String
>>>> }
>>>> 
>>>> -Patrick
>>>> 
>>>>> On Feb 13, 2016, at 12:38 PM, Donald Pinckney <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> 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> 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> 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
>>>>>>>> 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
>>>>>> 
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org
>>>>>> 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
>> 
>> _______________________________________________
>> 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/998a89d7/attachment.html>


More information about the swift-evolution mailing list