On 3/2/2022 2:36 PM, fo...@univ-mlv.fr wrote:

There are two ways to express "match non null Integer + unboxing",
this one
   Integer value = ...
   switch(value) {
     case Integer(int i) -> ...
   }

And we already agree that we want that syntax.

Wait, what?  The above is not yet on the table; we will have to wait for deconstruction patterns on classes to be able to express that. When we get there, we'll have a choice of whether we want to add a deconstructor to the wrapper classes.  (At which point, you might well say "we already have a way to do that"...)

You are proposing a new one
   Integer value = ...
   switch(value) {
     case int i -> ...
   }

But if it was on the table now, it would still not be particularly notable as a "new way" of anything; this would be true for *every single nested pattern*.  In fact, that's a feature, not a bug, that you can unroll a switch with a non-total nested pattern to a nested switch, and that is a desirable refactoring to support.

Obviously, your proposal makes things less simple because we new have to ways 
to say the same thing.

Not obvious at all.  Java's simplicity does not derive from "exactly one way to do each thing"; suggesting otherwise is muddying the terms for rhetorical effect, which is not helpful.

I think we do not need assignment conversions*and*  that introducing them makes 
the semantics harder to understand.

The former is a valid opinion, and is noted!


Reply via email to