On Thu, Jun 25, 2020 at 11:21 AM Kyle Knoepfel via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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(...).

-- 
Be seeing you,
Tony