Many thanks for the prompt response.

The first (quoted) response I choose to reject - the argument that "we
don't know how to scale X" holds no value to me. Someone else might.

The second (concrete example) response is valuable to me, as this is a
situation I had not considered, and it may or may not make my proposal
un-implementable. I'll have to think on it, and thanks for giving me
this feedback.

     Andrey Kapustin

On 21/06/2020 23:15, Arthur O'Dwyer via Std-Proposals wrote:
> On Sun, Jun 21, 2020 at 5:10 PM Michael Hava via Std-Proposals
> <std-proposals_at_[hidden]
> <mailto:std-proposals_at_[hidden]>> wrote:
>
> To quote the recent HOPL paper
> <https://www.stroustrup.com/hopl20main-p5-p-bfc9cd4--final.pdf> by
> Bjarne:
>
> Page 62: "There was always a group of people who wanted
> compile-time checks of which exceptions a
> function could throw. That, of course, works well in type theory,
> with small programs, with fast
> compilers, and with full control of the source code. The committee
> repeatedly rejected that idea on
> the grounds that it doesn’t scale to million-line programs
> developed and maintained by dozens (or
> more) organizations."
>
>
> Concretely, one of the ways C++ lets you write big programs "without
> full control of the source code" is templates.
> Andrey, you'd have to figure out what to do about templates:
>
> struct ErrA {};
> struct ErrB {};
> struct SA {
> void foo() throw(ErrA);
> };
> struct SB {
> void foo() throw(ErrB);
> };
> template<class T>
> void foo(T t) throw(???) {
> t.foo();
> }
>
> C++ already has several properties that can be propagated from callee
> to caller with enough effort: noexceptness, well-formedness (SFINAE).
> It has a few that cannot be propagated without loss: explicitness,
> overload-resolution-priority, constrainedness (C++20).
> At the moment, you're asking to add another property that can't be
> propagated. Can you fix that somehow?
>
> Herb Sutter's "Herbceptions" have basically the same problem with
> templates (last I checked): they add a new property that we'd like to
> propagate but it is ugly and/or inefficient to do so. I refer to these
> kinds of property as "colorations"; see e.g.
> https://quuxplusone.github.io/blog/2018/03/16/async-roundup/#the-concept-of-function-coloring (less
> about herbceptions)
> https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/A05A5feSZYI (more
> about herbceptions)
>
> In general I kind of like the idea of statically checking "this
> function may yield a result /or/ an ErrA, and so all callers must
> handle ErrA"; but if you're actually in that situation today, why not
> just return a `variant` or `Expected` type instead? C++ exceptions are
> what you use when you /want/ the set of yieldable things to be open-ended.
>
> –Arthur
>