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#.

The above proposal would lightly affect sections [except.pre] and [except.handle] of the standard. I will need to explore more how compiler parsers are affected--my brief perusal of GCC's parser indicates relatively simple changes would be required. I expect something similar with Clang, despite the very different implementation. I would not make any formal proposal until I have verified that (at the very least) GCC's and Clang's parsers can be reasonably adjusted.

I agree that such an addition introduces no new concepts to C++, nor is it intended to. The goal is to clean up parts of the language as a form of maintenance. For example, C++11 allowed cuddled closing angle brackets for nested templates (i.e. vector<T<U>> vs. vector<T<U> >). Such a change did not affect the meaning of a nested template, but it did make it easier to code. These cleanups do not warrant a new standard in themselves, but if they can be slipped in with more substantive changes, then they're worth it.

Cheers, and thanks again for your thoughts,
Kyle

> On Mon, Jun 22, 2020 at 9:39 PM Kyle Knoepfel via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > The catch-all handler sequence of a try-block is denoted by the 'catch (…)' syntax. My proposal is that the '(…)' characters could/should be removed (e.g.):
> >
> > try {
> > ...
> > }
> > catch (std::exception const& e) {
> > ...
> > }
> > catch { // i.e. no catch(...) anymore
> > ...
> > }
> >
> > The motivation here is two-fold: first, it is easier to read for the cases where access to the exception object is unnecessary; and second, it gets a closer to using ellipses for only variadic templates. My hope is that eventually C-style variadic arguments will be become a thing of the past, but that is not the topic of this post.
> >
> > In making the above suggestion, I am reminded of a response Ville made to one of my other ideas: "There's nothing impossible in it, but ideas that require changing every c++ parser on the planet need to cure cancer, and this idea doesn't." That is true enough in this case, but if influences from C are sometimes cancerous, then this is a step in the right direction.
>
> OK, but you said that "influences from C are *sometimes* cancerous".
> If that's your justification for the change, then you need to show
> that this particular use of `...` is *actually* cancerous. That it's
> fundamentally a problem in some respect other than that it is an
> "influence from C". Especially since `catch(...)` means something
> rather different from `function(...)`.
>
> I don't really see a sufficiently strong motivation here. C++ is not a
> clean language; it reuses and repurposes the same syntax for wildly
> different purposes in several cases. Removing precisely one instance
> of that will not change what C++ is. I know that sounds like "if you
> can't fix everything perfectly, don't fix anything at all", but this
> particular change is so trivial that I think it warrants more
> justification than being a step towards one day having a version of
> C++ where we "use ellipses for only variadic templates".
>
> Especially when the next step towards that world is decidedly unlikely
> to be taken.