[JEP 302] Method references with parameters

[Brian Goetz]

This has been requested a few times.

Think about where the motivation for this is coming from.  It goes 
something like this:
  - I prefer to use method references over lambdas when I can, they're 
prettier and (usually) more compact;
  - Here's a case where I could _almost_ use a method reference, but 
can't quite -- can't I stretch the syntax to get there?

If you think about where this goes, you'll see that it's a swan-dive 
down a slippery slope.  It starts with "can't I just curry one parameter 
on", but it won't stop there.  Pretty soon you're reinventing lambdas 
with a different syntax.

So, let's go back to why we added method references to the language in 
the first place.  Clearly they are not strictly needed -- any method 
reference can be expressed as an equivalent lambda. In this sense, 
method references are _weaker_ than lambdas; so why would we add a 
feature that is strictly weaker than another?

The goal of method references is not concision, or the ability to 
express something lambdas can't; it is the ability to express it _more 
transparently_.  Names matter; a lambda is an imperative bag of code, 
but a method reference makes a higher-level statement, saying "just 
reuse that thing over there, that already has a name."  A currying 
shorthand for method references is a cute trick, but the resulting 
construct has neither the flexibility of lambdas, nor the "I'm just a 
reference to an existing declaration" of method references.  Nor is it 
likely to be all that much more concise, either.

So, I think this feature suggestion offers little return-on-complexity, 
while at the same time, muddying the clarity of what method references are.

On 8/26/2018 6:45 PM, Chris wrote:
> I have a suggestion for JEP 302, while lambdas are being worked on: method
> references with parameters as a shorthand. For example,
> Integer::valueOf(2000) would be synonymous with () -> Integer.valueOf(2000)
> and byte[]::new(ARRAY_SIZE) with () -> new byte[ARRAY_SIZE].
>
> I'm guessing there's probably some reason this isn't already in the
> proposal, but can someone please explain it?
>
> Sincerely,
> Chris Hennick