Optional braces

[bearophile]

Walter:

Here you are essentially asking for a more global view of the D design, to see if we are using too much "plastic surgery". To have such global view we need to look at many unrelated things. So sorry if this looks like a lot of meat on the fire, there is no other way.


> We've already put a number of special cases in the grammar to ward off "bugs".

There is one more special case that we plan to disallow, that's not in DMD yet:

5409 Disallow (!x & y)
http://d.puremagic.com/issues/show_bug.cgi?id=5409

And there are few more special cases where I'd like to see changes/improvements on (there are other improvements that I'd like to see, but they aren't special cases):

3878 Arguments and attributes with the same name
4407 Catch wrong argument<->attribute assignments in methods
5187 Attribute hiding error or warning
5788 Return [] array
5807 Disallow mixed C/D style array declarations
6005 Type alias - variable name don't clash
6277 Disallow short floating point literals

(The enhancement request 6277 was discussed a lot, and generally accepted by people here.)


>But I worry that we might wind up tarting up the language with too many a boatload of them, to the point where it becomes a confusing mass. At what point should Meg Ryan stop with the plastic surgery? :-)<

This a valid concern. The purpose of the discussions here is right to weight advantages against disadvantages, and to see what one weights more. But to perform this weighting you have to consider all factors at the same time.

A well chosen "plastic surgery" in a language is often one that doesn't change the look of real world programs much. This is possible because a good rule is something that often wise programmers already follow when they write good code, or is something that is usually a bug anyway, like (!x & y).

Where possible it's good to base similar decisions on data and real usage. So:
- How many changes requires Phobos if the "else mismatch" syntax gets disallowed in D?
- Is this syntax change able to catch bugs in the already existing Phobos code? (and other good D2 code)?
- How much bad does it look D2 code if you introduce this grammar change? Is the result of this plastic surgery actually bad looking?

Such data helps answer the final question: are those disadvantages less important than the estimated amount of bugs caused by mismatch else?

My suggestion is to implement this small grammar change, compile Phobos with it, and then to take a look how much changes it requires, how much worse looking (if any) Phobos code becomes, and if this change finds any bugs in the code.

This will help take the decision.

In my experience in my D code there are causes of bugs more important than "else mismatch", like:

3878 Arguments and attributes with the same name
4407 Catch wrong argument<->attribute assignments in methods
3999 Enum equality to an int
5212 Safer typesafe variadics

So I care more for those enhancement requests than for "else mismatch".

Bye,
bearophile