Amber features 2026

[Archie Cobbs]

[ This is in reply to
https://mail.openjdk.org/pipermail/amber-spec-experts/2026-January/004306.html
on amber-spec-experts. ]

Hi Gavin,

The "Pattern Assignment" and "Constant Patterns" ideas sound good to me.
The "Pattern Assignment" idea is a natural way to extend pattern matching,
which is motivated by the frequent need to declare variables to access the
"variable components" in an instance of some object type.

My question is: Wouldn't the same motivation apply to generic type
parameters as well?

Here's a trivial example. Suppose we have this class:

    public record Property<T>(T value) {
        boolean has(T t) {
            return t == value;
        }
    }

and we want to write a method to check that a list of Property's are
well-behaved.

Here's what we'd LIKE to do, which is use "Pattern Assignment" for the
generic type variable:

    public void verifyHas(List<Property<?>> properties) {
        for (Property<?> element : properties) {
            <T> Property<T> property = element;
            T value = property.value();
            assert property.has(value);  // no cast needed here!
        }
    }

but here's what we HAVE to do today to avoid the unchecked cast:

    public void verifyHas(List<Property<?>> properties) {
        for (Property<?> property : properties) {
            verifyHas(property);
        }
    }

    // Ugh. This method exists solely to declare <T> so we can avoid an
unchecked cast
    private <T> void verifyHas(Property<T> property) {
        T value = property.value();
        assert property.has(value);
    }

If we're going to add "Pattern Assignment" it seems like it would be
reasonable for generic type variables to also benefit.

Cheers,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20260113/ccdad621/attachment.htm>