Reducing verbosity for generics

[Sam Carlberg]

An improved method for expressing the self-type would certainly help, I think. Though I can see it failing with inheritance in generics:

```
record Box<T>(T value) {}

class A {
Box<this.class> boxed() {
return new Box<>(this);
}
}

class B extends A {}

B b = new B();
A upcast = b;
Box<A> boxA = upcast.boxed();
Box<B> boxB = b.boxed();
```

Box<A>​ and Box<B>​ are incompatible types. So even though boxA​ and boxB​ are equivalent objects, we cannot assign boxA = boxB​ or have a method that accepts Box<A>​ also accept Box<B>​. Wildcards could help, except if your target demographic has little-to-no experience with generics.

Anyway. There's still the core issue that I'm trying to solve, which is giving meaningful names to complex generic types. Subclassing helps (and a "this" type would make it much better), but it still runs into issues where part of a library would want to use the base type and user code wants to use a subclass with a name meaningful to them (eg users wanting Velocity​ and library code wanting generic Quotient<A, B>​ which may or may not fit the Velocity​ type contract). I'm having a hard time seeing any solution other than allowing types to be aliased - there'd be no potential for incompatible inherited types there's no inheritance at all.
- Sam
On Monday, June 10th, 2024 at 7:00 PM, Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Mon, Jun 10, 2024 at 5:01 PM Olexandr Rotan <rotanolexandr842 at gmail.com> wrote:
>
>> Also, I am not sure that complexity of this approach really justified by solved problem.
>
> I agree, it's just a thought. The self-type hierarchy spam problem also creates a high level of pain/complexity though.
>
> I feel bad now for hijacking Sam's original email so I'll end my digression...
>
> -Archie
> --
>
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240610/cb1505e3/attachment.htm>