<div dir="ltr"><div>Thanks Brian, that helps.</div><div><br></div><div>For example, the idea of switching on a compile-time constant has always been conceptually 100% orthogonal to the type of that constant, and it really will be simpler when one day we can just switch on anything. That's a nice simplification<i> regardless</i> of whether anyone even uses the new ability. Anyone who wanted to switch on a long would expect it to just work, would have zero confusion about what the code meant if they encountered it, etc. It becomes easily understood as something that <i>always should have</i> worked -- there were just random "holes" in old versions that eventually got filled in. It's the best case.</div><div><br></div><div>Thanks to your explanation I see that this case is like that one in theory. It's not <i>quite </i>the same thing in practice. That is, I know that a person can both read and write "switch (someLong)" with no puzzlement, but I don't think the same is true here; enumness and genericness are <i>conceptually</i> orthogonal but most people can only come to that understanding through a bit of confusion first, and they can't necessarily guess the right syntax to use.</div><div><br></div><div>Secondly, it's hard to imagine there being any unforeseen consequences of switching on a long. Here, I don't really know how to think it through yet. I would appreciate any "here's how we know that the changes we need to support this will have no user-visible consequences at all except for X, Y, and Z" type of explanation we have (apologies if I missed it).</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 12, 2018 at 9:01 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div>Yes, you could spin this feature as “its sort of for experts”, note the incremental complexity, and then raise the “why bother” flag.  That’s a valid question.  </div><div><br></div><div>But, I prefer to look at this feature in a different way.  This is not, IMO, just “let’s make enums do more.”  This is about _simplifying_ the language model by removing gratuitous interactions between features.  Enums are a constrained form of classes, one whose instances are singletons managed by the runtime.  Because the user gives up instance control, we’re able to reward the user with things like equals/hashCode/toString, serialization, etc.  That’s a good trade.  Enums can still use most of the things that classes have — fields, methods, constructors, interfaces. But there’s no reason they can’t be generic, and allowing that would reduce the inessential differences between enums and classes.</div><div><br></div><div>The other asymmetry is newer; since we inferred sharp types for anonymous classes when we did LVTI, inferring a weaker type for enum constants is now an asymmetry (one we were aware of when we did LVTI, but the plan all along was to align these.)</div><div><br></div><div>I know that I personally have run into both of these limitations at least once in every large project I’ve ever done.  You start out with an enum, for good reasons, then you hit the limits, and then have to refactor to classes, manually inflating the instance control boilerplate.  Its frustrating, in part, because its unnecessary.  There’s nothing inconsistent about generic enums; it’s just an accidental “pick one” constraint that you discover when you find yourself wanting both.  </div><div><br></div><div>So, I prefer to look at this feature as “regularization” or “removing gratuitous interactions”, rather than “making enums more complicated.”  (It’s in the same category as some other things we’re considering, such as allowing local methods, or refining the awful rules about static members in nested classes.)  All of these are accidental sharp edges, that create unnecessary cognitive load for users to keep track of which features can be used in conjunction with which others.  </div><div><br></div><br><div><blockquote type="cite"><div>On Dec 12, 2018, at 11:40 AM, Kevin Bourrillion <<a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a>> wrote:</div><br class="gmail-m_-1417760509261683217Apple-interchange-newline"><div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 12:25 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>> wrote:<br></div><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This uber-conservative approach seems a pretty reasonable approach to <br>
me; after all, enums are a language feature, and Enum<T> is a <br>
constrained class (can't implement it directly), so it is not <br>
unreasonable to define its typing wrt its supertypes specially.<br>
<br>
So, let's get back to Maurizio's original question, which is: At one <br>
point, we thought this feature was pretty cool, and invested some work <br>
in it.  Then we ran into a roadblock, and wrote it off.  Now, we've got <br>
a reasonable way to clear the roadblock. Which brings us back to:<br>
<br>
  - Do we still like the features described in JEP 301?<br></blockquote><div><br></div><div>What proportion of enum use cases benefit from this? Offhand, I would have to guess that it is less than 0.1% (and if it turned out to be <i>far</i> less it wouldn't <i>shock</i> me). Does anyone believe it's <i>likely enough</i> to be >0.1% that it's worth my effort to try to research that question in our codebase (which would take a bit of work)?</div><div><br></div><div>If not, and we can stipulate that the need is rare, this means it will be a very special tool for very special people; a dark corner in the language feature set that most Java developers will never have need to know -- until they suddenly encounter code that uses it, upon which they need to invest an amount of effort understanding what is going on, even though they may have 14 years of believing they understood enums under their belts already. And if the need is this rare, this effort they put in might never be fully paid back.</div><div><br></div><div>On the flip side, for a developer who does have this use case, and could benefit from the feature, what are the chances that developer will even know about it? It may be so special-purpose that we have no real reason to assume they'll know what to do.</div><div><br></div><div>On top of this, it seems the feature apparently has a blast radius onto aspects of enum design that have previously been stable.</div><div><br></div><div>Can a 0.1% use case ever really be worth this?</div><div><br></div></div>-- <br><div dir="ltr" class="gmail-m_-1417760509261683217gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div></div>
</div></blockquote></div><br></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div>