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

[Dave Abrahams]

on Tue Apr 26 2016, Tony Allevato <swift-evolution at swift.org> wrote:

> On 2016-04-26 22:32:16 +0000, Dave Abrahams via swift-evolution said:
>
>> The main reasons to route through a single generic operator
>> implementation are:
>>
>> * User experience; we want to cut down the number of overloads of any
>>   operator to a manageable set, in part because they live in the global
>>   namespace.  When you look at a list of functions in the global
>>   namespace, seeing fifty instances of `func +` is not helpful.
>>
>> * Type checker speed.  Having all of these overloads around has
>>   historically put a strain on the type checker and made compilation
>>   slow.  That may be less true today than it once was, though.
>
> These are both completely understandable concerns (especially the type
> checker speed, since I've hit the "expression too complex" problem in
> a couple odd places myself). I'm hoping though that we can converge on
> a solution other than "pollute the public interface of a type with
> named methods that duplicate the operators, which are trampolines to
> those methods", since I think that actually detracts from the user
> experience of using that type.
>
> Would something like this be possible? Imagine protocols defined like this:
>
>    public protocol Equatable {
>        static func == (lhs: Self, rhs: Self) -> Self
>    }
>    public protocol FloatingPoint: Equatable {
>        static func + (lhs: Self, rhs: Self) -> Self
>    }
>
> This would have the effect of automatically generating the following
> generic trampoline global operators:
>
>    public func == <T: Equatable>(lhs: T, rhs: T) -> T {
>        return T.==(lhs, rhs)
>    }
>    public func + <T: FloatingPoint>(lhs: T, rhs: T) -> T {
>        return T.+(lhs, rhs)
>    }
>
> Then, types that conform to FloatingPoint would define the method as
> appropriate:
>
>    public struct Double: FloatingPoint {
>        public static func == (lhs: Double, rhs: Double) -> Double { ... }
>        public static func + (lhs: Double, rhs: Double) -> Double { ... }
>    }
>
> If something like this worked, it has a number of advantages:
>
> * It has the same lower overhead with respect to the global namespace
> as the currently proposed strategy that uses an explicitly defined
> generic operator that trampolines to a named add() method. This should
> keep type checking fast and keeps the number of global instances of
> the operator low.
> * It increases consistency: the operator requirement is declared in
> the protocol, and the concrete implementation is *in* the conforming
> type (as opposed to a separate global function).
> * There is no need to introduce arbitrarily named methods to implement
> the operations that would pollute the public interface of the type.
> * It doesn't affect the ability to pass operators as first-class
> functions into other algorithms (like + into reduce). In fact, if an
> algorithm needs to be explicit about the types (if they can't be
> inferred for some reason), then for example `Float.+` would refer to
> the appropriate `(Float, Float) -> Float` function.
>
> Some might argue that implicitly defining the generic global operator
> under the covers is a drawback to this approach, but I think that's a
> minor concern when weighed against the alternatives.
>
> Individual elements of the syntax could be debated (an "operator"
> keyword instead of "static func"? But that might just be syntactic
> sugar), but overall, I'd love to get feedback on the feasibility of an
> approach like this. I'm happy to take a stab at drawing this up in a
> proposal, as well.

Hi Tony,

As you can see in the notes from April 27, 2016 language review, the
core team discussed this.  Although one member had some reservations, I
think it would be very worthwhile for you to write the proposal that
allows static operator methods, and soon.  In Swift 3, we think the
trampolines have to be manual, rather than automatically-generated, and
we are unsure that automatic generation can work at all, so I strongly
recommend that you take up that possibility in a follow-on proposal if
you think it's important.

Thanks for the great idea!

-- 
Dave