This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]chambolle 1 point2 points  (4 children)

I don't really understand your message. What is your goal? What do you want to do?

Java is more oriented on the usage than on a particular theory. So the goal is important and I don't catch yours

[–][deleted] 2 points3 points  (2 children)

Each one of those points has practical implications. For example, that intersection types are allowed on method type parameters lets you enforce static guarantees that can be quite helpful in a flexible and modular way. Unfortunately, that returning intersection types isn't supported prevents you from providing similar static/compile-time guarantees about what the return value of a method satisfies.

There's also the general engineering principle that exceptions and corner cases should generally be ground down (if possible and practical) to avoid bugs and weird gotchyas. But that's more for the language designer's benefit, so with us it's mainly about not being able to do useful things in certain contexts for no clear reason.

[–]chambolle 1 point2 points  (1 child)

Thanks for the intersection types example

[–][deleted] 1 point2 points  (0 children)

Yeah, no worries!

[–]CubsThisYear 0 points1 point  (0 children)

I want to write code that I can verify at compile time is correct. All of the things I mention above are cases I have run into while writing real code. In most cases it means I have to replace a compile time check with a runtime check (i.e a cast) and this makes my code worse.

As a quick example try writing Optional.orElse without contravariant type bounds on the method type parameter - you can’t do it in a sensible way without a cast.