Jason, thank you for your response. One thing I've learned is to not use someone else's metaphor! I'd like to take a more reasoned stab at this proposal. So, backing up...
The proposal is that the catch-all exception handler could be spelled in two ways:
catch { } // undecorated syntax, which is semantically identical to
catch ( … ) {} // current syntax
This is a pure language extension, breaking no currently well-formed code. There are various motivations for allowing the undecorated syntax:
- Less visual noise, and thus easier to read
- Fewer characters to type, reducing potential compile-time errors (how many dots did I type?)
- Easier for teaching newcomers to the language (why do I need to put these funny dots here?)
Similar undecorated syntax is found in Ruby, Python, and C#.
These benefits are all valid, but are they worth the cost?
The cost isn't in the parser or even the wording. The costs are:
- committee time. _Nothing_, even the most perfect proposal, is quick and easy in the committee. Committee time is finite. Is this the best use of it?
- harder to learn - "there are two different syntaxes, what does each do, why are there two, etc"
- (and we can't NOT teach the old syntax, because you will see it in code for years and years)
- team arguments over coding style
- do we deprecate the old style some day (and if so, see "committee time")
catch(...) is ubiquitous. So it makes it hard to change. If we want to eventually evolve away from it we can, but it will take 20-30 years.
There are some similarly ubiquitous changes that I'd like to make in spite of the required long timelines, but they might still be worth it. I don't think catch (...) is worth it.
Of course, if the real benefit is to eventually have ... mean something else, then there might be value. But again, you are looking at 20+ years to deprecate/remove catch(...).