[swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

[Tony Allevato]

That seems like a purely syntactic concern that could potentially be
addressed in other ways, though. I'm not sure the choice of "duplicate all
operators using verbosely-named methods" is the best one for the reasons I
mentioned above, and the question of "how do we cleanly unify operators
with other protocol requirements?" seems out-of-scope and orthogonal to
this proposal.

Given that we already have existing cases in the language where operators
are declared within protocols (`Equatable` being the first one that comes
to mind), I would recommend that this proposal follow that pattern for
consistency and then the community continue a separate discussion about
operators in protocols, which may or may not lead to changes across the
entire language and standard library. The protocol operators discussion
feels like a much larger topic that deserves to be discussed in its own
right without bogging down the rest of this proposal.


On Tue, Apr 26, 2016 at 8:18 AM David Sweeris <davesweeris at mac.com> wrote:

> I’m with Nicola on this one. Operators are currently odd in that they have
> to be declared globally. Everything else about protocol conformance is kept
> within the conforming type.
>
> - Dave Sweeris
>
>
> On Apr 26, 2016, at 9:28 AM, Tony Allevato via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> > > func isEqual(to other: Self) ->Bool
>> > > func isLess(than other: Self) ->Bool
>> > > func isLessThanOrEqual(to other: Self) ->Bool
>> >
>> > I'm still not sure why these are methods instead of operators.
>>
>> I think this is an *excellent* choice, and I hope it is the first step to
>> completely removing operators from protocols.
>>
>> IMHO throwing operators into protocols is inconsistent and confusing.
>> Having regular methods and a single generic version of the operator that
>> calls down on the type’s methods is clearer and guarantees that generic
>> code can avoid ambiguities by calling the methods directly, instead of
>> having to rely only on heavily overloaded global operators.
>>
>
> I personally disagree on this point. To me, a protocol describes a set of
> requirements for a type to fulfill, which includes things other than
> methods. Just as a protocol can define initializers, properties, and
> associated types that a type must define in order to conform, it makes
> sense that a protocol would also define which operators a conforming type
> must support.
>
> Introducing a mapping between names and operators poses a few problems:
>
> – IMO, they are overly verbose and add noise to the definition. This makes
> the language look less clean (I'm getting visions of NSDecimalNumber).
> – They expose two ways to accomplish the same thing (writing
> `x.isEqual(to: y)` and `x == y`).
> – Do certain operators automatically get mapped to method names with
> appropriate signatures across all types, or does a conforming type still
> have to provide that mapping by implementing the operators separately? If
> it's the latter, that's extra work for the author of the type writing the
> protocol. If it's the former, does it make sense to automatically push
> these operators for all types? Should any type that has an `add` method
> automatically get `+` as a synonym as well? That may not be desirable.
>
> I'm very supportive of the floating-point protocol proposal in general,
> but I feel the arithmetic and comparison operations should be exposed by
> operators alone and not by methods, where there is a suitable operator that
> has the intended meaning.
>
>
>
>>
>> —
>> Nicola
>>
>> _______________________________________________
>> 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/20160426/fbd81e31/attachment.html>