isEqual to replace == Equatable Requirement


(Richard Fox) #1

Hi all,

I would like to propose changing the Equatable protocol to use isEqual(to:Self)
-> Bool, defined inside of a type to replace the currently used
operator == function,
which is defined outside of the type.
<https://gist.github.com/Nadohs/308603afa65cbbfba07c#reasoning>Reasoning:

   1. Having the conforming function defined inside of the type is more
   intuitive, since in general functions required for conformance are defined
   within the type. It feels like an unnecesary detail for learners of Swift
   to have to stumble through.

The implementation for this would look something like this:

     public protocol Equatable{
       ....

       /// Shortcut for defining `==` function inside type definition.
       @warn_unused_result
       func isEqual(to:Self) -> Bool
     }

     @warn_unused_result
     public func == <T : Equatable>(lhs: T, rhs: T) -> Bool {
         return lhs.isEqual(rhs)
     }

<https://gist.github.com/Nadohs/308603afa65cbbfba07c#impact-on-existing-code>Impact
on Existing Code:

This implementation would break existing code, but could be fixed with a
default protocol extension such as:

     /// Default `isEqual` function to satisfy other types only definiting
     /// `==` for equality.
     public extension Equatable{
         func isEqual(to:Self) -> Bool{
             return self == to
         }
     }

Not adding the default function for isEqual makes more sense to me though,
since it would remove any strict requirement for Equatable conformance and
leave no warning for the loop you would create by implementing neither
isEqual nor ==.

Regards,
Rich Fox


(Joe Groff) #2

Long term we'd like to make it so that operators can be methods of their operand types, either instead of or in addition to being globals. That seems like a better way of addressing these concerns.

-Joe

···

On Dec 8, 2015, at 2:01 AM, Richard Fox via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

I would like to propose changing the Equatable protocol to use isEqual(to:Self) -> Bool, defined inside of a type to replace the currently used operator == function, which is defined outside of the type.

<https://gist.github.com/Nadohs/308603afa65cbbfba07c#reasoning>Reasoning:

Having the conforming function defined inside of the type is more intuitive, since in general functions required for conformance are defined within the type. It feels like an unnecesary detail for learners of Swift to have to stumble through.
The implementation for this would look something like this:

     public protocol Equatable{
       ....

       /// Shortcut for defining `==` function inside type definition.
       @warn_unused_result
       func isEqual(to:Self) -> Bool
     }

     @warn_unused_result
     public func == <T : Equatable>(lhs: T, rhs: T) -> Bool {
         return lhs.isEqual(rhs)
     }
<https://gist.github.com/Nadohs/308603afa65cbbfba07c#impact-on-existing-code>Impact on Existing Code:

This implementation would break existing code, but could be fixed with a default protocol extension such as:

     /// Default `isEqual` function to satisfy other types only definiting
     /// `==` for equality.
     public extension Equatable{
         func isEqual(to:Self) -> Bool{
             return self == to
         }
     }
Not adding the default function for isEqual makes more sense to me though, since it would remove any strict requirement for Equatable conformance and leave no warning for the loop you would create by implementing neither isEqual nor ==.

Regards,
Rich Fox
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Nicky Gerritsen) #3

Although I like the idea, I think it should be more general, as this same reasoning also holds for other operators.
Wouldn't it be better to allow to define operators within a type? So that we can just implement == in the type?

I do not know how hard it is to implement it or if this is even possible. Probably it is hard, because otherwise it would already have been done?

Regards,

Nicky

···

On 12/08/2015 11:01 AM, Richard Fox via swift-evolution wrote:

      Hi all,

I would like to propose changing the Equatable protocol to use >isEqual(to:Self) -> Bool|, defined inside of a type to replace the currently used operator |==| function, which is defined outside of the type.

      <https://gist.github.com/Nadohs/308603afa65cbbfba07c#reasoning>Reasoning:

1. Having the conforming function defined inside of the type is more
    intuitive, since in general functions required for conformance are
    defined within the type. It feels like an unnecesary detail for
    learners of Swift to have to stumble through.

The implementation for this would look something like this:

>public protocol Equatable{ .... /// Shortcut for defining `==` function inside type definition. @warn_unused_result func isEqual(to:Self) -> Bool } @warn_unused_result public func == <T : >(lhs: T, rhs: T) -> Bool { return lhs.isEqual(rhs) } |

      <https://gist.github.com/Nadohs/308603afa65cbbfba07c#impact-on-existing-code>Impact
      on Existing Code:

This implementation would break existing code, but could be fixed with a default protocol extension such as:

>/// Default `isEqual` function to satisfy other types only definiting /// `==` for equality. public extension Equatable{ func isEqual(to:Self) -> Bool{ return self == to } } |

Not adding the default function for |isEqual| makes more sense to me though, since it would remove any strict requirement for Equatable conformance and leave no warning for the loop you would create by implementing neither |isEqual| nor |==|.

Regards,
Rich Fox

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


(Ling Wang) #4

That'll be great!

···

_____________________________
From: Joe Groff via swift-evolution <swift-evolution@swift.org>
Sent: Tuesday, December 8, 2015 11:57 AM
Subject: Re: [swift-evolution] isEqual to replace == Equatable Requirement
To: Richard Fox <fox.ios.dev@gmail.com>
Cc: <swift-evolution@swift.org>

       Long term we'd like to make it so that operators can be methods of their operand types, either instead of or in addition to being globals. That seems like a better way of addressing these concerns.
       -Joe
                  On Dec 8, 2015, at 2:01 AM, Richard Fox via swift-evolution < swift-evolution@swift.org> wrote:
                  Hi all,
       
I would like to propose changing the Equatable protocol to use isEqual(to:Self) -> Bool, defined inside of a type to replace the currently used operator == function, which is defined outside of the type. Reasoning: Having the conforming function defined inside of the type is more intuitive, since in general functions required for conformance are defined within the type. It feels like an unnecesary detail for learners of Swift to have to stumble through.

The implementation for this would look something like this: public protocol Equatable{ .... /// Shortcut for defining `==` function inside type definition. @warn_unused_result func isEqual(to:Self) -> Bool } @warn_unused_result public func == <T : Equatable>(lhs: T, rhs: T) -> Bool { return lhs.isEqual(rhs) } Impact on Existing Code:

This implementation would break existing code, but could be fixed with a default protocol extension such as: /// Default `isEqual` function to satisfy other types only definiting /// `==` for equality. public extension Equatable{ func isEqual(to:Self) -> Bool{ return self == to } } Not adding the default function for isEqual makes more sense to me though, since it would remove any strict requirement for Equatable conformance and leave no warning for the loop you would create by implementing neither isEqual nor ==.
        
Regards,
Rich Fox _______________________________________________
swift-evolution mailing list
      swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Hart) #5

Your proposition makes comparison code much less readable only for a small benefit at the point of definition. I'd vote against.

···

On 08 Dec 2015, at 11:06, Nicky Gerritsen via swift-evolution <swift-evolution@swift.org> wrote:

Although I like the idea, I think it should be more general, as this same reasoning also holds for other operators.
Wouldn't it be better to allow to define operators within a type? So that we can just implement == in the type?

I do not know how hard it is to implement it or if this is even possible. Probably it is hard, because otherwise it would already have been done?
Regards,

Nicky

On 12/08/2015 11:01 AM, Richard Fox via swift-evolution wrote:
Hi all,
I would like to propose changing the Equatable protocol to use isEqual(to:Self) -> Bool, defined inside of a type to replace the currently used operator == function, which is defined outside of the type.

Reasoning:

Having the conforming function defined inside of the type is more intuitive, since in general functions required for conformance are defined within the type. It feels like an unnecesary detail for learners of Swift to have to stumble through.
The implementation for this would look something like this:

     public protocol Equatable{
       ....

       /// Shortcut for defining `==` function inside type definition.
       @warn_unused_result
       func isEqual(to:Self) -> Bool
     }

     @warn_unused_result
     public func == <T : Equatable>(lhs: T, rhs: T) -> Bool {
         return lhs.isEqual(rhs)
     }
Impact on Existing Code:

This implementation would break existing code, but could be fixed with a default protocol extension such as:

     /// Default `isEqual` function to satisfy other types only definiting
     /// `==` for equality.
     public extension Equatable{
         func isEqual(to:Self) -> Bool{
             return self == to
         }
     }
Not adding the default function for isEqual makes more sense to me though, since it would remove any strict requirement for Equatable conformance and leave no warning for the loop you would create by implementing neither isEqual nor ==.

Regards,
Rich Fox

_______________________________________________
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

I'd rather support defining operator functions inside the type:

    extension Foo: Equatable {
        func ==(rhs: Foo) -> Bool {
            return self.bar == rhs.bar
        }
    }

Is there any reason this wouldn't work?

Stephen

···

On Tue, Dec 8, 2015 at 8:36 AM, David Hart via swift-evolution < swift-evolution@swift.org> wrote:

Your proposition makes comparison code much less readable only for a small
benefit at the point of definition. I'd vote against.

On 08 Dec 2015, at 11:06, Nicky Gerritsen via swift-evolution < > swift-evolution@swift.org> wrote:

Although I like the idea, I think it should be more general, as this same
reasoning also holds for other operators.
Wouldn't it be better to allow to define operators within a type? So that
we can just implement == in the type?

I do not know how hard it is to implement it or if this is even possible.
Probably it is hard, because otherwise it would already have been done?

Regards,

Nicky

On 12/08/2015 11:01 AM, Richard Fox via swift-evolution wrote:

Hi all,

I would like to propose changing the Equatable protocol to use isEqual(to:Self)
-> Bool, defined inside of a type to replace the currently used operator
== function, which is defined outside of the type.
<https://gist.github.com/Nadohs/308603afa65cbbfba07c#reasoning>Reasoning:

   1. Having the conforming function defined inside of the type is more
   intuitive, since in general functions required for conformance are defined
   within the type. It feels like an unnecesary detail for learners of Swift
   to have to stumble through.

The implementation for this would look something like this:

     public protocol Equatable{
       ....

       /// Shortcut for defining `==` function inside type definition.
       @warn_unused_result
       func isEqual(to:Self) -> Bool
     }

     @warn_unused_result
     public func == <T : Equatable>(lhs: T, rhs: T) -> Bool {
         return lhs.isEqual(rhs)
     }

<https://gist.github.com/Nadohs/308603afa65cbbfba07c#impact-on-existing-code>Impact
on Existing Code:

This implementation would break existing code, but could be fixed with a
default protocol extension such as:

     /// Default `isEqual` function to satisfy other types only definiting
     /// `==` for equality.
     public extension Equatable{
         func isEqual(to:Self) -> Bool{
             return self == to
         }
     }

Not adding the default function for isEqual makes more sense to me
though, since it would remove any strict requirement for Equatable
conformance and leave no warning for the loop you would create by
implementing neither isEqual nor ==.

Regards,
Rich Fox

_______________________________________________
swift-evolution mailing listswift-evolution@swift.orghttps://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


(Richard Fox) #7

I dont see how this makes it less readable, are you taking into
consideration that you still use == everywhere for comparison, after
defining with isEqual? As this method would be defined in the stdlib.

public func == <T : Equatable>(lhs: T, rhs: T) -> Bool

···

On Tue, Dec 8, 2015 at 5:36 AM David Hart <david@hartbit.com> wrote:

Your proposition makes comparison code much less readable only for a small
benefit at the point of definition. I'd vote against.

On 08 Dec 2015, at 11:06, Nicky Gerritsen via swift-evolution < > swift-evolution@swift.org> wrote:

Although I like the idea, I think it should be more general, as this same
reasoning also holds for other operators.
Wouldn't it be better to allow to define operators within a type? So that
we can just implement == in the type?

I do not know how hard it is to implement it or if this is even possible.
Probably it is hard, because otherwise it would already have been done?

Regards,

Nicky

On 12/08/2015 11:01 AM, Richard Fox via swift-evolution wrote:

Hi all,

I would like to propose changing the Equatable protocol to use isEqual(to:Self)
-> Bool, defined inside of a type to replace the currently used operator
== function, which is defined outside of the type.
<https://gist.github.com/Nadohs/308603afa65cbbfba07c#reasoning>Reasoning:

   1. Having the conforming function defined inside of the type is more
   intuitive, since in general functions required for conformance are defined
   within the type. It feels like an unnecesary detail for learners of Swift
   to have to stumble through.

The implementation for this would look something like this:

     public protocol Equatable{
       ....

       /// Shortcut for defining `==` function inside type definition.
       @warn_unused_result
       func isEqual(to:Self) -> Bool
     }

     @warn_unused_result
     public func == <T : Equatable>(lhs: T, rhs: T) -> Bool {
         return lhs.isEqual(rhs)
     }

<https://gist.github.com/Nadohs/308603afa65cbbfba07c#impact-on-existing-code>Impact
on Existing Code:

This implementation would break existing code, but could be fixed with a
default protocol extension such as:

     /// Default `isEqual` function to satisfy other types only definiting
     /// `==` for equality.
     public extension Equatable{
         func isEqual(to:Self) -> Bool{
             return self == to
         }
     }

Not adding the default function for isEqual makes more sense to me
though, since it would remove any strict requirement for Equatable
conformance and leave no warning for the loop you would create by
implementing neither isEqual nor ==.

Regards,
Rich Fox

_______________________________________________
swift-evolution mailing listswift-evolution@swift.orghttps://lists.swift.org/mailman/listinfo/swift-evolution

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


(David Hart) #8

Well in that case I find even more confusing that to implement equality you have to define a function which is different from the operator.

···

On 08 Dec 2015, at 18:43, Richard Fox <fox.ios.dev@gmail.com> wrote:

I dont see how this makes it less readable, are you taking into consideration that you still use == everywhere for comparison, after defining with isEqual? As this method would be defined in the stdlib.

public func == <T : Equatable>(lhs: T, rhs: T) -> Bool

On Tue, Dec 8, 2015 at 5:36 AM David Hart <david@hartbit.com> wrote:
Your proposition makes comparison code much less readable only for a small benefit at the point of definition. I'd vote against.

On 08 Dec 2015, at 11:06, Nicky Gerritsen via swift-evolution <swift-evolution@swift.org> wrote:

Although I like the idea, I think it should be more general, as this same reasoning also holds for other operators.
Wouldn't it be better to allow to define operators within a type? So that we can just implement == in the type?

I do not know how hard it is to implement it or if this is even possible. Probably it is hard, because otherwise it would already have been done?
Regards,

Nicky

On 12/08/2015 11:01 AM, Richard Fox via swift-evolution wrote:
Hi all,
I would like to propose changing the Equatable protocol to use isEqual(to:Self) -> Bool, defined inside of a type to replace the currently used operator == function, which is defined outside of the type.

Reasoning:

Having the conforming function defined inside of the type is more intuitive, since in general functions required for conformance are defined within the type. It feels like an unnecesary detail for learners of Swift to have to stumble through.
The implementation for this would look something like this:

     public protocol Equatable{
       ....

       /// Shortcut for defining `==` function inside type definition.
       @warn_unused_result
       func isEqual(to:Self) -> Bool
     }

     @warn_unused_result
     public func == <T : Equatable>(lhs: T, rhs: T) -> Bool {
         return lhs.isEqual(rhs)
     }
Impact on Existing Code:

This implementation would break existing code, but could be fixed with a default protocol extension such as:

     /// Default `isEqual` function to satisfy other types only definiting
     /// `==` for equality.
     public extension Equatable{
         func isEqual(to:Self) -> Bool{
             return self == to
         }
     }
Not adding the default function for isEqual makes more sense to me though, since it would remove any strict requirement for Equatable conformance and leave no warning for the loop you would create by implementing neither isEqual nor ==.

Regards,
Rich Fox

_______________________________________________
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