[swift-evolution] isEqual to replace == Equatable Requirement

[Stephen Celis]

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 at 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 at 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 at swift.orghttps://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/20151208/d096d06d/attachment.html>