I agree and disagree.
I agree that range checking of other ranges is useful and something that
belongs on the "candidate features" list. In fact, it's been on my list
for a while.
But I disagree that this is the time or place for it, or the best way to
do it. Range checking may be one way to view "instanceof byte", but a
more general way is that is the precondition for safely casting to
byte. And the language defines casting rules not only from other
integral types, but from floating point types as well.
That said, we've been keeping our eye on ranges in general, since they
are useful in lots of places besides patterns, such as:
// loops
for (int i : 1..10) // we can argue over inclusive vs exclusive
for (int i : array.range()) // range returns a Range<int>, which
is Iterable<int>
// case labels
case 1..10: ...
We could do this today, but we could do better tomorrow with features
coming from Valhalla. This is how I'm thinking we'll get there.
On 11/16/2022 11:50 AM, Tagir Valeev wrote:
Hello!
From what I see, `instanceof byte`, `instanceof short`, `instanceof
char` and `instanceof int` applied to a wider integral value are four
range-checking conditions. In many cases, people may want to check
against different (but compile-time constant) range. It looks too
restrictive to support only four specific ranges. I understand the
rationale about symmetry between primitive and reference types but the
usefulness looks very limited to me. Supporting custom ranges, like
`instanceof int(>0) x` or `instanceof byte(0..100) b` or something
like this (with dominance and exhaustiveness checks in switch) would
be much more useful. I agree that this would also require much more
work, but at least it would be nice to take this in mind as a possible
future improvement.
With best regards,
Tagir Valeev.
On Tue, Nov 15, 2022 at 12:20 AM Angelos Bimpoudis
<[email protected]> wrote:
Dear experts,
The draft JEP for adding support for primitive types in instanceof and type
patterns, that has been previously discussed on this list, is available at:
https://bugs.openjdk.org/browse/JDK-8288476
Suggestions are welcomed!
Angelos
