Money for Nothing, ...

[David Alayachew]

Hello Rémi,

To start off, Nothing is only going to take you a short distance. Nothing
works decently enough for the type T. But for the Exception, Nothing will
not work as a type parameter because the type parameter it is supposed to
be matching is E, and E extends Exception. Nothing does not extend
Exception (presumably), and even if it did, this would be a constantly
growing problem that we do not want to put into the language. What if you
need R to extend List<String>, for example?

But a bigger question I have is, why are you attempting to do this?
Superficially, it makes sense -- you want to be able to make it immediately
obvious that the Success only deals with the T, and doesn't even have a
concept for the Exception. Vice versa for Error.

But those are loose guard rails. Nothing is preventing (or should I say,
there are no blockers preventing) me from throwing in my Success. Or
treating the value in Error like a return type. Obviously, misuses, but I
raise them to point out how, even in this theoretical example, the generic
type parameters don't seem to give you anything.

And finally, this sort of sounds like an XY Problem to me (
https://en.wikipedia.org/wiki/XY_problem). Is there a pre-existing, larger
problem that led you to trying to find a solution this way? And if so, I'd
like to hear it.

Thank you for reaching out!
David Alayachew

PS - In situations like this, I tend to reach for the Void Class (
https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/Void.html).
To my understanding, the only value that can ever match a Void Class is
null. You cannot create an instance of Void, and thus, cannot have an
instance to pass in (as long as you aren't breaking reflection or
something). That said, it is an aggravating workaround, and anytime I feel
the need to do this, it is usually a clue that I need to change strategies.
I usually only use Void so that I can see the "bad solution", then refactor
it into something more usable while maintaining the semantics/functionality.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20230614/2324c9cb/attachment-0001.htm>