<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 10/5/2018 7:22 PM, Dan Smith wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7F5E0D67-0A18-47E0-9767-D474BA4E52D7@oracle.com">
<div class="">- It's not totally clear what we do with 'this'.
Kind of seems like it should be treated as the first parameter
to be passed, but there are also examples in the JEP that ignore
it. And is it allowed to be referenced by the receiver
expression?</div>
<div class=""><br class="">
</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>void
reverse() = Collections::reverse; // invoke
Collections.reverse(this)?</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>int
length(String s) = String::length; // invoke s.length()?</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>void
altMethod() = ThisClass::method; // invoke this.method()?</div>
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>void
altMethod2() = this::method; // legal?</div>
</blockquote>
<br>
<tt>Drilling in on `this`: <br>
<br>
One of the strongest motivating examples was:<br>
<br>
static final Comparator c = ...<br>
<br>
int compareTo(T other) = c::compare;<br>
<br>
And in this case, we want this to wire to c.compare(this, other).
<br>
<br>
However, another strong motivating case is: <br>
<br>
final List myList = ...<br>
<br>
int size() = myList::size;<br>
<br>
in which case we want this to wire to myList.size() and ignore
`this` entirely. <br>
<br>
And, both use cases are equally desirable. <br>
<br>
We have some precedent for resolution that involves "try both",
which is the Class::method syntax, where we'll match either an
instance method or a static method passing the receiver as the
first parameter. However, this is a little different; in that
case, we were still using all the parameters, just adapting them
to paper over the somewhat accidental static/instance divide. In
this case, we want to drop the receiver when the wired-to method
doesn't want it, which is a little messier. But, also not totally
novel; when adapting a value-returning method reference to a
void-returning SAM, we are willing to drop the return value. <br>
<br>
There are (at least) two ways we could attack this. The first
involves refining the "infer a target type from the method
descriptor, and then use that for overload selection" intuition.
Just as with Class::method, where we use the target type to do
overload selection for both static and instance methods, and fail
if we find neither or both, we can do the same thing; construct
both the with-receiver and without-receiver SAM, and fail if there
is not exactly one answer. <br>
<br>
The other approach, which also leans on an existing precedent, is
to start with the method reference; if it exact, use that to
condition the adaptation to the implied SAM. Which is slightly
weaker that the first approach, as the exactness test can be
fooled by inapplicable overloads (say, with completely wrong
arity, or incompatible types.) <br>
<br>
We already discourage overloads like:<br>
<br>
class C {<br>
static R x(C c, ARGS)<br>
R x(ARGS)<br>
}<br>
<br>
because that will make method references C::x ambiguous. With the
approaches above, we'd also have ambiguities in cases like:<br>
<br>
class X {<br>
void m() = Bar::m;<br>
}<br>
<br>
class Bar {<br>
static void m(X x, ARGS) { }<br>
static void m(ARGS) { }<br>
}<br>
<br>
</tt>That seems somewhat unlikely, but it becomes slightly more
imagineable when you have something like:<br>
<br>
<tt> class X implements I {<br>
void m() = Bar::m;<br>
}<br>
<br>
class Bar {<br>
static void m(I i, ARGS) { }<br>
static void m(ARGS) { }<br>
}<br>
<br>
But still, it doesn't seem like we'd be overrun with these.<br>
<br>
<br>
Summary:<br>
<br>
- Both the capture-this and drop-this cases have important
motivating use cases<br>
- Arbitrarily dropping one or the other would compromise the
feature<br>
- There are some possibly reasonable ways of doing overload
resolution and adaptation here, at some complexity.<br>
<br>
<br>
<br>
</tt>
</body>
</html>