<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I tend to agree. I’d like the inconsistency concerning operators and dispatch to be resolved by investigating making operators into members, not by forcing operators to be second-class citizens. (Obviously this deserves its own proposal and its own discussion.)</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 26, 2016, at 08:47, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Apr 26, 2016 at 8:18 AM David Sweeris <<a href="mailto:davesweeris@mac.com" class="">davesweeris@mac.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">- Dave Sweeris</div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 26, 2016, at 9:28 AM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> > func isEqual(to other: Self) ->Bool<br class="">
> > func isLess(than other: Self) ->Bool<br class="">
> > func isLessThanOrEqual(to other: Self) ->Bool<br class="">
><br class="">
> I'm still not sure why these are methods instead of operators.<br class="">
<br class="">
I think this is an *excellent* choice, and I hope it is the first step to completely removing operators from protocols.<br class="">
<br class="">
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.<br class=""></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Introducing a mapping between names and operators poses a few problems:</div><div class=""><br class=""></div><div class="">– IMO, they are overly verbose and add noise to the definition. This makes the language look less clean (I'm getting visions of NSDecimalNumber).</div><div class="">– They expose two ways to accomplish the same thing (writing `x.isEqual(to: y)` and `x == y`).</div><div class="">– 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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><span style="line-height:1.5" class=""><br class=""></span></div><div class=""><span style="line-height:1.5" class=""> </span><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="">
—<br class="">
Nicola<br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>