[swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols
Dave Abrahams
dabrahams at apple.com
Wed Apr 27 13:07:03 CDT 2016
on Wed Apr 27 2016, Stephen Canon <swift-evolution at swift.org> wrote:
>> On Apr 27, 2016, at 1:54 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> on Tue Apr 26 2016, Chris Lattner <swift-evolution at swift.org> wrote:
>>
>>> On Apr 26, 2016, at 7:34 PM, Tony Allevato via swift-evolution <swift-evolution at swift.org> wrote:
>
>>>> Would something like this be possible? Imagine protocols defined like this:
>>>>
>>>> public protocol Equatable {
>>>> static func == (lhs: Self, rhs: Self) -> Self
>>>> }
>>>
>>> The problem is that every type that conforms to Equatable has to
>>> provide an overload of == in order to conform. This is exactly what
>>> having named methods as requirements solves.
>>
>> Note that Tony is proposing to make the requirement static. Whether
>> it's actually called “==” or isEqual is almost immaterial, because the
>> fact that it is static makes it less likely that anyone will try to call
>> it directly.
>>
>> However, if we allowed static operators to be defined, and called using
>> the syntax “T.==(x,y)”, as Tony has suggested, IMO it would further
>> discourage direct use, and it would avoid growing the number of
>> truly distinct spellings for the same operation.
>>
>> That would also remove many instances of “formXXX” methods that
>> currently cause many people discomfort. Whether that's a win or not
>> depends on whether you view widespread discomfort with “formXXX” as a
>> nuisance or a beneficial forcing function for finding something better
>> ;-)
>
> Personally I like this, but t’s not totally clear how it would extend
> to mutating operations. `T.+=(x: inout T, y: T)`?
Well, that looks like a mix between a decl and a use. I presume you
mean
static func +=(x: inout T, y: T)
and
T.+=(&x, y)
That seems like the obvious answer to me.
>
>
> – Steve
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
--
Dave
More information about the swift-evolution
mailing list