Revert "Fix Issue 22019 - case 1,: allowed by grammar but not DMD"

[WalterBright]

Reverts #12677

No evidence that it is needed, and it's ugly.

[wilzbach]

Consistency matters and there's still no reason not to allow this.

[CyberShadow]

No evidence

Yes evidence: #12677 (comment)

[dkorpel]

Yes evidence: #12677 (comment)

To give a bit more context, when I started learning D and learned that "trailing commas are allowed" I thought it was one more of those common sense quality of life things that D had over Java, just like nested comments /++/, underscores in number literals, multiline string literals etc. When I later figured out that it didn't work in case statements, it was one of those "D feels unfinished" moments. Not a big deal, but it needlessly tripped me up.

The only argument against it is "it looks ugly", but that's subjective and not a strong reason to disallow it. I personally think this looks ugly:

if (x)
{
    one();
    two();
}
else
    single();

That doesn't mean I think the parser should reject it.

[WalterBright]

Yes evidence: #12677 (comment)

"needed" is a strong word. Every error reported by the parser is not ipso facto a need to change the language. @dkorpel apparently had no difficulty adding the extra logic needed. As I've pointed out, hdrgen.d doesn't need trailing commas to successfully generate code. It's trivial to do this. There's nothing clever about hdrgen.d. DMD's json generator doesn't have any problems needing a trailing comma, either. I'm not seeing the need.

"it looks ugly", but that's subjective and not a strong reason to disallow it.

Yes, it is subjective, and aesthetics matter a lot. The language is designed to favor looking good over being an easy language to generate code for. D expressions would use postfix notation rather than infix if generating source code was the priority. Postfix (and prefix) notation languages exist, and aren't very popular.

Bits of inconsistency also allow the compiler to detect user errors better, too.

D feels unfinished

To be fair, that's subjective, too. Just like case 1,: is ugly. Note that C and C++ allow trailing commas in initializers, but not argument lists. In 40 years I never heard anyone say that needs to change, and people are hardly quiet about wanting changes to those languages.

An anecdote - long ago, I worked on graphical user interface. I had everything nice and consistent. People hated it because human aesthetic sense simply is not based on mathematical consistency. Source code on the screen is quite definitely a GUI.

For a D anecdote, the original way D looked up imported symbols was simple and utterly consistent. Perhaps some of you remember those discussions. Everyone but me insisted that "consistency" with this involved numerous special cases, and two passes over the symbol table. If you look at the code to implement this "consistency", it is anything but consistent logic. But people were happier with that, so it stayed. This happened again with namespaces, consistency wasn't what people wanted.

D's grammar and language rules are full of inconsistencies, because people simply do not like consistent languages. People take things on a case-by-case basis.

P.S. The same goes for airline cockpit design. Consistency doesn't work there, either. Each control is uniquely shaped and has its own unique feel, this is to help the pilot know he's got his hand on the throttle rather than the thrust reverser, etc.

[dkorpel]

Yes, it is subjective, and aesthetics matter a lot. The language is designed to favor looking good over being an easy language to generate code for.

D expressions would use postfix notation rather than infix if generating source code was the priority. Postfix (and prefix) notation languages exist, and aren't very popular.

Postfix is easier to parse, but not much easier to generate than infix. For generating infix expressions, you can simply add parentheses always, since the compiler doesn't reject redundant parentheses. Notice that this compiles:

int x = ((((((((((((((((((((((((((((((((((((((((3))))))))))))))))))))))))))))+((((((((((((((((((((((((4))))))))))))))))))))))))))))))))))));

Not because it looks good, but because it's consistent. The compiler should accept good style, not reject bad style. That's the job of a linter. "%s %s".writefln = ("foo".tuple = "bar").expand; is bad style, but valid D. (Taken from Hackerpilot's "idiomatic.d").

Bits of inconsistency also allow the compiler to detect user errors better, too.

How does disallowing a trailing comma give better error messages?

the original way D looked up imported symbols was simple and utterly consistent
Perhaps some of you remember those discussions.

I don't, do you have a link? If there are inconsistencies in importing symbols I'd like to be aware of them 🙂

D's grammar and language rules are full of inconsistencies, because people simply do not like consistent languages. People take things on a case-by-case basis.

P.S. The same goes for airline cockpit design. Consistency doesn't work there, either. Each control is uniquely shaped and has its own unique feel, this is to help the pilot know he's got his hand on the throttle rather than the thrust reverser, etc.

No programmer will say "I'm glad this trailing comma got rejected by the compiler, now I know I'm in a case statement and not an initializer list".

[dkorpel]

Note that C and C++ allow trailing commas in initializers, but not argument lists. In 40 years I never heard anyone say that needs to change, and people are hardly quiet about wanting changes to those languages.

"don't care about other languages"