Submission: switch (...) instanceof feature

[Jeroen van Maanen]

Artur Biesiadowski wrote:
> 1) Why case void: instead of case null: ?

Yes, I agree that it is potentially confusing. At the other hand, null is an instance not a type. It would also be possible to add a type or even a keyword to describe the type of null, but that would increase the impact of the change and it would mean another type with no instances. I thought that void would pretty much fit the descrition of what I would like: a keyword that indicates a type that would not have any actual instances. I suppose that if we are stretching the exact meaning of the terms anyway, then 'case null:' would probably just be as well and easier to remember.

> 2) What is a expected behavior in case of multiple matches ? For example

I propose to do strict top-down first-match-only evaluation, because if the given variable matches many of the labels and the types of the labes belong to a complicated hierarchy of interfaces, then reordering the cases according to inheritance could lead to unpredictable results. I don't think that executing all matching blocks would be a good idea, because I think that many code readers would not expect this from a switch statement. Although it would be possible to allow a fallthrough from a specific type to a super type, I am afraid that allowing such highly constrained constructions would lead to code that is hard to read and easy to misunderstand.

> switch(collection) instanceof {
> 
> case RandomAccess:
>    ...
> 
> case List:
>   ...
> 
> case Collection:
>  ...
> 
> 
> }
> 
> Do I need to put switch cases in correct order because of top-to-down 
> evaluation or most specific one will be used? Or maybe all matching ones ?
> 
> 3) I think you have forgotten to put 'break' in your examples, unless 
> you plan to disallow fall-through.

Ah, I should have made that explicit. No breaks necessary and no lists of labels before a statement block. I could not think of a way to get the  casts right in a fallthrough situation. Maybe it would be less confusing to make break a compulsory statement at the end of each statement block. That is:

  TypeSwitchBlockStatementGroup:
    TypeSwitchLabel BlockStatements break ;

What do you think?

> Regards,
> Artur Biesiadowski

I just thought about another situation that needs to be clarified:

4) How does the switch instanceof statement handle generics?

I would like to see

switch (model) instanceof {
FreeMarkerModel:
  template.process(..., model);
Map:
  template.process(..., toFMM(model))
}

translated as

if (model instanceof FreeMarkerModel) {
  FreeMarkerModel model$1 = (FreeMarkerModel) model;
  template.process(..., model$1);
}
else if (model instanceof Map<?,?>) {
  Map<?,?> model$2 = (Map<?,?>) model;
  template.process(..., toFMM(model$2));
}

So each type parameter that we cannot guess would be specified as ?.

The following would be illegal, because the specification allows no type parameters after the type name in a label.

switch (model) instanceof {
...
Map<String,Object>:
...
}

This is fine, because I can't think of a way where the desugared code would be free of "unchecked" warnings.

Regards,  Jeroen