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.
<gist:308603afa65cbbfba07c · GitHub
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
}
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 ==.
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.
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
}
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 ==.
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.
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) } |
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 |==|.
_____________________________
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 ==.
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 ==.
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.
<gist:308603afa65cbbfba07c · GitHub
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
}
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 ==.
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.
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.
<gist:308603afa65cbbfba07c · GitHub
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
}
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 ==.
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.
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 ==.