KEEP VS amber-docs

`Either foo()` and `Foo foo() throws MyError` and are pretty much isomorphic.

https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/...

Nice. So for example, it looks like Kotlin has a nearly identical feature at the language level which will be optimizable when Valhalla ships: https://github.com/Kotlin/KEEP/blob/master/notes/value-class...

> In the future, in a Valhalla-capable JVM, JVM primitive classes will enable efficient representation of Kotlin value classes with an arbitrary number of underlying fields on JVM.

Most other languages agree that checked exceptions are not good by not having them.

As for alternatives, Try/Result and similar monads have decent adoption even in Java, but personally I quite like the Kotlin philosophy [1] to not have generic error containers and either use runtime exceptions or make failures of the return type.

[1] https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/...

If you want to read more and don't want to google it: https://github.com/Kotlin/KEEP/blob/data-objects/proposals/data-objects.md

Under the hood: https://github.com/Kotlin/KEEP/blob/master/proposals/coroutines.md .

you can check more here

You can use explicit API mode, then everything needs explicit visibility

Record patterns are one step on the path to general pattern matching utility. The bigger building block is general deconstructors. I recommend reading Functional Transformation of Immutable Objects by Brian Goetz. The idea of "withers" shown there requires deconstructors:

https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

This is the vague plan.

You may be joking but...

Here is the much more detailed version: https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md

This kind of pattern matching is discussed in the design notes: https://github.com/openjdk/amber-docs/blob/master/site/design-notes/patterns/pattern-match-object-model.md

True, but that only pushes the question of value down the line.

I'm curious about lenses because Java did have a serious problem that required a solution: working with "simple" data correctly was difficult. The chosen solution was ADTs, so we did buy into that. But the approach being explored for transforming records (https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...) only works one level at a time rather than for an entire path. So I wonder how valuable it would be to have a solution for paths. If the answer is that it's mostly valuable for an approach we haven't bought into yet, then we might not need to consider it just yet.

Just a heads up, something like that spread operator is actually coming sooner or later to java: https://github.com/openjdk/amber-docs/blob/master/eg-drafts/...

Pattern matching (for records) is already a preview feature.