clarity needed for the non-sealed keyword

[Brian Goetz]

While one can get used to anything (e.g., lispers don't give a second 
thought to identifiers with question marks in them), I think the hyphen 
is pushing up against the edge of what Java users can get used to right 
now (and some of them are having a hard time at that, this thread being 
evidence of that.)  Just imagine what the typical Java user would say to 
"non#null".  I think that's asking too much of users.

Stewardship is balancing what is achievable technically (without 
drowning ourselves in future technical debt) with what is good for the 
users.  It's always a difficult balance.



> Hi Brian,
>
> One of the points which has not been considered, is using an ASCII
> letter which has not been used by any other standard tokens(operator,
> separator) e.g. using one of # or ` (hash or backtick)
> Yes, it may not be natural, so was the _(underscore) when it was used
> in a numeric literal, but readibility was good _(underscore),
> similarly using a # instead of
> hyphen in new keywords may also be considered. It would not have the
> problem of ambiguity, and readibility will not be as bad.
>
> The hyphenated keywords require a look ahead, which consumes white
> spaces including new-line characters. This would be possible for
> compilers and IDEs to manage to some extend but, a very big ask for
> the REPL tools like jshell.
>
> I tried using non-sealed on a separate line with jshell to define a
> non-sealed class, but it is getting tokenized as three tokens.
> I could easily define an abstract class by starting with abstract on a
> separate line, but this doesn't work for non-sealed keyword.
>
> I understand that # may not look good, but if could be used, then
> there are less problems.
>
> Thanks and regards,
> Pravin
>
> On Fri, Oct 9, 2020 at 1:10 AM Brian Goetz <brian.goetz at oracle.com> wrote:
>>
>>> But why does the keyword contain a “-”?  Why wasn't “nonsealed” good
>>> enough?
>> The rationale for the creation of hyphenated keywords is well
>> documented.  See, for example:
>>
>> http://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-January/000945.html
>>
>> and
>>
>> https://openjdk.java.net/jeps/8223002
>>
>>
>