Small things Java lets you do, but not everywhere.

[Jeremy Barrow]

Heyo, I just wanted to send off a quick email about some of the things that
I think would be easy pickings for Amber to tackle.
More specifically, they're things in the language that are either not
completely fleshed out due to lack of interest, or, more likely, for some
technical reason.

The first one is definitely array literals:

I've been using Java for 7ish years at this point, and honestly, I don't
even know if I'm gonna get this right.
The only place I'm aware of array literals being valid is for a field write.

Not many people use arrays, as Lists are just better, but _very_
occasionally you do have to reach for an array.
It would be nice if we could expand the array literal use case.
Just about everywhere an expression could be expected, I think an array
literal could be valid.
I can image `return` statements working really well with it, and with the
new expression switch, the break with value.


I'll be honest, this is where the "easy pickings" part is no longer true.


Class local generics (Field local generics?):

I definitely think I'm not the only one who has written some static field
that has a map which maps some arbitrary data container to some value, with
the data container containing some type parameter that tells you what the
value type is.

`private static final Map<Key<?>, ?> data = ...`

It would be a massive boon, if we could write that as something like:

`private static final <T> Map<Key<T>, T> data = ...`

Otherwise we have to cast everything we pull out of the map.
I know it's of the correct type, but the compiler doesn't.
This leads to some annoying stuff where generics aren't actually helping
you, which is a bit counter intuitive.
We have generics for methods, theoretically, it should be possible for
fields.

Union types:
Now, I'll preface this with this might be difficult to translate into the
VM right now, so erasure might be the only option for now (With type
signatures being a possible route in the future).

In a nutshell, declaring fields with union types.
Right now, I either have to declare three different fields, making my
memory usage suffer if I have tons of these objects (Which I normally do,
because this specific class is a Token class for a lexer, and I parse
massive input sources), also making it more error prone due to having three
different ways to access the same data.
Granted union types won't solve the last problem, but it doesn't help it.
Technically, Java does have union types in catch signatures.
Obviously, the catch signatures kinda get "collapsed", so it's not really
the same, as there's a lot more needed under the hood here.
Possibly.
I think a quick prototype might be just to treat it as though I had written
something like, and just erase it to Object:
`private final <T extends String | Integer | Double> T data;`
Obviously, we don't have union generics, so that would obviously have to be
added, and honestly, I think that might be the can of worms I didn't plan
on.


So, I'll wrap it up there.
Obviously, the generics and union types are quite.. large in scope, and
aren't really easy, but I do think the array literals are something that
could be touched on.

Cheers,
Jeremy.