> On Apr 6, 2018, at 1:58 PM, Brian Goetz <brian.go...@oracle.com> wrote:
> 
> 
>>> 
>>>     int index=-1; 
>>>     switch (s.hashCode()) { 
>>>         case 12345: if (!s.equals("Hello")) break; index = 1; break; 
>>>         case 6789: if (!s.equals("World")) break; index = 0; break; 
>>>         default: index = -1; 
>>>     } 
>>>     switch (index) { 
>>>         case 0: ... 
>>>         case 1: ... 
>>>         default: ... 
>>>     } 
>>> 
>>> If there are hash collisions between the strings, the first switch must try 
>>> all possible matching strings. 
>> 
>> I see why you use this structure, because it fits a general paradigm of 
>> first mapping to an integer.
> 
> Or, "used", since this is the historical strategy which we're tossing over 
> for the indy-based one. 

Sorry, I incorrectly interpreted some of the transitional text.
> 
>> I now suggest that a post-optimization might then turn this into:
>> 
>>   SUCCESS: {
>>     DEFAULT: {
>>       switch (s.hashCode()) { 
>>         case 12345: if (s.equals("Hello")) { stmts1; break SUCCESS; } else 
>> if (s.equals(“Goodbye")) { stmts3; break SUCCESS; } else break DEFAULT;
> 
> Yes; the thing that pushed us to this translation was fallthrough and other 
> weird control flow; by lowering the string-switch to an int-switch, the 
> control structure is preserved, so any complex control flow comes along "for 
> free" by existing int-switch translation.  Of course, it's not free; we pay 
> with a pre-switch.  (When we added strings in switch, it was part of "Project 
> Coin", whose mandate was "small features", so it was preferable at the time 
> to choose a simpler but less efficient desugaring.)  

Oops, I forgot about preserving fallthrough.  Yuck.  “Never mind."

Well, the post-optimization can still be used in situations where no 
fallthrough occurs.  Can decide later whether it is worth the trouble to avoid 
the integer encoding.

Reply via email to