RFR: 8255398: Add a dropReturn MethodHandle combinator [v3]

Jorn Vernee jvernee at openjdk.java.net
Mon Oct 26 17:32:20 UTC 2020


On Mon, 26 Oct 2020 17:16:17 GMT, John R Rose <jrose at openjdk.org> wrote:

>> LGTM, pending CSR.
>> 
>> A minor simplification suggested inline.
>
> I don't mind shorthands, but the existing idiom is shorter than advertised,
> a one-liner assuming the MH is already bound to a var:
> 
> target = target.asType(target.type().changeReturnType(void.class));
> 
> The API has good short circuits already; no new objects are
> created if the MH is already void-returning.
> 
> Perhaps this RFE could be adjusted to `MethodHandle::changeReturnType`?
> Then it could be used for dropping returns *or* casting them to other types.

@rose00 My bad. You're right, I realized we could also use `asType` later on (I did call it out in the CSR), but It's still a bit more wordy than what I'm proposing.

`dropReturn` seemed like a good choice since we already have `dropArguments`. WRT changing to `MethodHandle::changeReturnType`, I think doing that also begs for adding a `MethodHandle::changeParameterType` (with a single index and varargs overload). But, in that case it seems fair to just point users at `asType` instead.

In other words; `dropReturn` seems fine to get parity with `dropArguments`, but `changeReturnType` seems a step too close to `asType` (also since it implies adding `changeParameterType` as well). So, maybe this RFE is a bust, and users should use `asType` instead? Or do you think adding both `changeReturnType` and `changeParameterType`(s) seems worth it? (I'm not so sure).

-------------

PR: https://git.openjdk.java.net/jdk/pull/866


More information about the core-libs-dev mailing list