RFR: 8334722: Error emitted when switch expression does not yield any value lacks reasoning [v3]

[Evemose]

On Mon, 24 Jun 2024 08:41:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Sorry, but I am not quite sure what's the problem with the (existing) error, and if the new one is better.
> 
> There are two reasons for that:
> a) the specification:
> https://docs.oracle.com/javase/specs/jls/se22/html/jls-15.html#jls-15.28.1
> literally says:
> 
> > It is a compile-time error if a switch expression has no result expressions.
> 
> It does not say it is a compile-time error is that the switch expression's type cannot be determined (see below), but that it is an error if there are not result expression. And while trouble determining the expressions type are likely a part of the motivation for this assertion, it is not the only one, I think.
> 
> b) for code like:
> ```
>     private void c() {
>         test(switch (0) {
>             default -> 0;
>         });
>     }
>     private void test(int i) {}
> ```
> the type of the switch expression is not determined by the result expressions, but by the target type. I.e. in this case, the type of the expression is `int`, regardless whether there is any `yield` returning `int` or not. It would, in principle, be possible to permit no result expression in cases like this, I think. It is unclear what would be the usefulness of that, though.
> 
> 
> 

Firstly, I would like to note that I don't view this as an issue, that's why I filed issue as enhancement, not a bug.

Now with this said, I guess it would be appropriate to identify problem more formally. I would formulate it as something as following: "Switch expression have requirement to contain at least one branch that results in value yielded at least in one of possible execution execution scenarios, unlike the switch statements. The previous error, *while provides explanation on how to fix this compilation error*, does not explain why it is reported. It *is* confusing due to inconsistency between switch expression and statement".

This issue is an enhancement and not a bug, because compiler does not have to "explain itself" if it at least explains a way to fix it. However, noone was ever hurt by more robust error reporting. 

Now to some statements in my problem description. Why I say it *is* confusing instead of it *could* be confusing. Well, because this confusion got even to jdk mailing lists. Also, I don't think personal experience is a good argument to provide, but I also encountered question regarding this error quite a bunch of times when I introduced someone to Java.

As for new error message itself, I couldn't be 100% sure, but when this question got to amber mailing list, I spent some time looking through javac codebase and the only place where this error is reported is Attr class, which is responsible for attribution (which includes type determination). That's why I say that inability to attribute type to switch expression is the *effective* cause of this error. I'm not sure if specification designers put more meaning in this than I am, but the other thoughts, at least, didn't make it to javac codebase (of course if I haven't missed some other place where this issue is reported, although I doubt it).

To yield part: im not sure if it is strictly correct, but I always thought of non-void one-expression lambdas as ones that imolecitly return the value. Moreover, if you look into decompiled sources, generated return statements is exactly what you will see. That's why I also have always thought that whether yield keyword is specified explicitly or not, value is always *yielded*.

That's my reasoning behind it. If you find it insufficient or find improvement not significant enough to be integrated, I could close the issue, no problem in it, I don't think lost results of those enormous efforts to change one line in errors file are too significant to be upset about after all lol.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19837#issuecomment-2186011093