Dot Product Thoughts

Brian Goetz brian.goetz at
Fri Apr 19 05:41:04 PDT 2013

No, because then you're overloading integer sum and long sum, which 
invites overload selection / inference issues with:


and both

   (int, int) -> int
   (long, long) -> long

may be acceptable candidates.

Methods specifically designed to be used as method refs should not be 

Inference is great.  Overloading is great.  But overloading and 
inference are pulling in opposite directions; much of the time we can 
still deliver a good result, but that doesn't mean we should design 
libraries that make inference failure more likely.  (Many languages that 
are heavily based on type inference don't have overloading for this 
reason, except on arity.)

On 4/19/2013 6:39 AM, Stephen Colebourne wrote:
> On 19 April 2013 01:42, Brian Goetz <brian.goetz at> wrote:
>>>>      Sensible would be the ability to express all built-in operators as
>>>>      functions so they can be used as reducers.
>>> I'm a bit confused: are you describing a language change that would
>>> allow any operator to be used as a function, or adding more static
>>> overloads to primitive classes and Strings?
>> Just more static methods in classes like Integer.
> Maybe instead of:
> Integer::opSum
> Integer::opMultiply
> It could be:
> Opertators::sum
> Opertators::multiply
> Just a thought
> Stephen

More information about the lambda-dev mailing list