`this` in concise method bodies
Dan Smith
daniel.smith at oracle.com
Fri Oct 12 18:08:56 UTC 2018
> On Oct 12, 2018, at 11:15 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
> 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 intuition I would lean on is overload resolution. The '=' that binds a method implementation is an overloaded operator, because there are multiple function types that could be suitable.
void bindCompareToImplementation(ToIntFunction<T> mref);
void bindCompareToImplementation(ToIntBiFunction<Foo,T> mref);
void bindSizeImplementation(IntSupplier mref);
void bindSizeImplementation(ToIntFunction<Foo> mref);
{
bindCompareToImplementation(c::compare);
bindSizeImplementation(myList::size);
}
(This also makes me less worried about extra complexity—it's the kind of complexity we already handle in overload resolution.)
More information about the amber-spec-experts
mailing list