Do you really think they just forget about it?
It has a purpose:
https://mail.openjdk.org/pipermail/amber-dev/2020-April/0058...
I still disagree though. First, there is precedent with interfaces and abstract methods, which also leave out the method body and terminate with a semicolon.
Second, the point here is that you almost always leave the body of a record empty, while you rarely do so for a class or method.
They are worried that if you use arcane constructs like non-static initializers, the syntax might become confusing - but are fine if you have clutter in the common case. That seems backwards to me.
Edit: You can construct the exact same confusing situation that the thread warns against already today, with abstract methods:
public abstract void foo(); {
System.out.print("I don't have anything to do with foo!");
}
The email exchange didn't talk about that kind of confusion; in fact, it said `;` was an option. It just said that saving one or two keystrokes isn't worth it to break the rule that type declarations end in `}` while statements end in `;`.
> there is precedent with interfaces and abstract methods, which also leave out the method body and terminate with a semicolon.
Abstract methods aren't type declarations and they have no body. Also, they've been in Java since day one. It's conceivable that down the line, people will be so used to records that we'll allow `;` to terminate the definition. It's just that we've gone down from a page of code to one line, and adding another rule to save one character isn't worth it at this time.
I think it's not really about the keystrokes (though { } is harder to type on my keyboard than ; ) but more that this technically opens a new class block, which gets treated as such by build tools, IDEs, etc.
E.g. formatters want to put the braces on different lines by default and are generally tuned to put class blocks front and center - because with all the other occurrences of class blocks, that's the sensible thing to do. With records, it just undoes the neat "just one line" property.
Yes, you can add custom formatting rules to stop that, but that's additional effort - you also have to ensure everyone uses the new formatting, etc.
It's also more cognitive effort to parse the code: Imagine the GROUP BY clause were mandatory in SQL and if you didn't want to use grouping in your query, you'd have to write something like "GROUP BY 1". Certainly doable but makes queries harder to read.
> type declarations end in `}` while statements end in `;`.
That rule already has lots of exceptions, e.g. methods are not type declarations (like you said) and neither are initializers. Nevertheless, both use braces and leave out the ; at the end.
I am not an author of that particular feature, but I work with them on OpenJDK.
> Yes, you can add custom formatting rules to stop that, but that's additional effort ... It's also more cognitive effort to parse the code
Perhaps, but using `;` has its own downsides (it's different from all other type declarations both for readers and for the language's grammar). The choice is never between something good and something bad, but between two things that are both good and bad.
Given that a record can save you tens of lines, on the whole it was decided that it's not worth it to add a new rule that saves a single additional character at this time. It can always be added later.
> That rule already has lots of exceptions, e.g. methods are not type declarations (like you said) and neither are initializers. Nevertheless, both use braces and leave out the ; at the end.
That's not the rule, though. I didn't mean that only type declarations use {}, but that all type declarations use {}. I don't think there are any exceptions.
It would be cool if we could have some kind of pragma or alternate syntax (file extension?) that gets rid of these unwanted ambiguities every decade or so. How to do that while avoiding the whole “Perl 6” can of worms might be the hard part though.
Perl 5 seems to have all these annoying boilerplate lines that you need to add to every file in order to get “Perl The Good Parts”. But I think (I read) that they managed to boil it down to just one line.