`this` in concise method bodies

[Victor Nazarov]

What if we force user to disambiguate this two cases.
We already have syntax to do it:

````
static final Comparator c = ...

int compareTo(T this, T other) = c::compare;
````

vs

````
final List<String> myList = ...

int size() = myList::size;
````

--
Victor Nazarov


On Fri, Oct 12, 2018 at 8:16 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> On 10/5/2018 7:22 PM, Dan Smith wrote:
> > - 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?
> >
> > void reverse() = Collections::reverse; // invoke
> > Collections.reverse(this)?
> > int length(String s) = String::length; // invoke s.length()?
> > void altMethod() = ThisClass::method; // invoke this.method()?
> > void altMethod2() = this::method; // legal?
>
> Drilling in on `this`:
>
> One of the strongest motivating examples was:
>
>      static final Comparator c = ...
>
>      int compareTo(T other) = c::compare;
>
> And in this case, we want this to wire to c.compare(this, other).
>
> However, another strong motivating case is:
>
>      final List myList = ...
>
>      int size() = myList::size;
>
> in which case we want this to wire to myList.size() and ignore `this`
> entirely.
>
> And, both use cases are equally desirable.
>
> 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.
>
> 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.
>
> 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.)
>
> We already discourage overloads like:
>
>      class C {
>          static R x(C c, ARGS)
>          R x(ARGS)
>      }
>
> because that will make method references C::x ambiguous.  With the
> approaches above, we'd also have ambiguities in cases like:
>
>      class X {
>          void m() = Bar::m;
>      }
>
>      class Bar {
>          static void m(X x, ARGS) { }
>          static void m(ARGS) { }
>      }
>
> That seems somewhat unlikely, but it becomes slightly more imagineable
> when you have something like:
>
>      class X implements I {
>          void m() = Bar::m;
>      }
>
>      class Bar {
>          static void m(I i, ARGS) { }
>          static void m(ARGS) { }
>      }
>
> But still, it doesn't seem like we'd be overrun with these.
>
>
> Summary:
>
>   - Both the capture-this and drop-this cases have important motivating
> use cases
>   - Arbitrarily dropping one or the other would compromise the feature
>   - There are some possibly reasonable ways of doing overload resolution
> and adaptation here, at some complexity.
>
>
>
>