Auto-generate op==?

Evolution Discussion
1

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,

2

+1, but...

I don't know what the actual reason this isn't in the language is, but the main issue I see is that there isn't a generic way to iterate over the properties of a struct or class. This *might* change if the proposal for iterating over a tuple goes through... An object could, I think, store all its non-computed properties in a tuple, and if *that* is equatable, then a generic == could probably be written.

The obvious reply is, "Well then why not use compiler magic", to which I say, "Because it's better to extend the language than to rely on compiler magic."

IMHO, this sounds like is one of several suggestions that most people will probably want, but that simply can't be done until Swift gains either a mechanism for generically processing tuples, and/or a macro system, both of which have been declared out of scope until it's time to start talking about Swift 3.

- Dave Sweeris

···

On Feb 12, 2016, at 14:47, Daniel Tartaglia via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

3

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

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@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@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@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

5

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@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@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@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@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

6

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.

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@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@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@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@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@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

7

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@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

8

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@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@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@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@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@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@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

9

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@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@swift.org <mailto:swift-evolution@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@ucdavis.edu <mailto:djpinckney@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

10

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

···

Le 13 févr. 2016 à 15:54, Daniel T. via swift-evolution <swift-evolution@swift.org> a écrit :

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@ucdavis.edu <mailto:djpinckney@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

11

That is Haskel’s Algebraic Data Type is it not? I would think the Swift equivalent would be an `enum` (enumeration). (just one case) — unless of course you had something like

enum InvolvedParty {
    case Person(name: String, age: Int)
    case Organization(name: String)
}

The only problem with Swift is that it becomes cumbersome to use if you only had one case… having to refer to it as InvolvedParty.Person when initializing the value.

And yes as far as I know it has no auto definition of equatable.

···

On 2016-02-14, at 0:12:48, Donnacha Oisín Kidney via swift-evolution <swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

12

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@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@gmail.com <mailto:devteam.codafi@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@swift.org <mailto:swift-evolution@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@ucdavis.edu <mailto:djpinckney@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

13

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.

I'd worry that this might lead us into the same territory that got memberwise init into trouble.

···

--
Brent Royal-Gordon
Architechies

14

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@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@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@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@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@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@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@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@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@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

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

15

I could say the same about any derived implementation, as you may not to check to be 100% sure that ever property is valid for the comparison. I get that extending the derived function has other complexities, but I’ve had complex types in the past (not in Swift) that would have been a lot cleaner if I could just use the derived result for most values, then tweak a few somehow. I just think it’s worth considering, even if that’s just “yeah we could do that later maybe”, but it’s a possible reason for preferring an actual keyword as it that same keyword could then be used in the extended operator.

Either way I think we still need an attribute so that properties can be opted out of the auto-generation, as it lets the feature be used on types with cache properties and other values that don’t need to be compared, which extends its usefulness to more cases; I can think of a dozen or so of my own types which essentially just have boiler-plate equality operators, but which also have properties that need to be ignored, so couldn’t make the switch to auto-generation.

Also, I just wanted to add as well that my vote’s for a derived/deriving keyword; the # prefix for compiler directives suggests to me that something may be compiled away, however if we’re using it to mark Equatable then this isn’t the case as the result is still always going to be Equatable. One other alternative is to just use some kind of decorative “magic” protocol, e.g- AutoEquatable (extending Equatable) that is handled with some compiler magic in the short term, and perhaps some other mechanism in future once we get reflection and other goodies.

···

On 14 Feb 2016, at 03:44, danielt1263@gmail.com wrote:

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@haravikk.me <mailto:swift-evolution@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.