Good morning,

I'll have to think on what you wrote, and I thank you for the feedback. Nevertheless, I'm not sure I understand your
reasoning entirely (unless I'm missing something) - so, please, elaborate.

To explain: to me a "programming-by-contract" always meant the perception of functions (methods) as "services" which "require"
something from the caller and, in return, "ensure" something on behalf of a callee. If I were to use a HYPOTHETICAL P-B-C syntax
in a C/C++ case, I could write:

=========================================================================
char * strchr(const char * str, int ch)
  require: str != nullptr;
  require: ch != 0;
  ensure: (result == nullptr) || (result >= str && result < (str + strlen(str)) && *result == ch);
{ /* implementation */ }
=========================================================================

Maybe this is influenced by me knowing only Eiffel as a language that has a direct support for "programming-by-contract"
(I have developed another C-level one, but that's not important in this context). This, by the way, is a feature that I would ALSO 
like to see becoming a part of C++ standard, but I see no way of it ever becoming accepted by the C++ committee.

What's the difference from the "checked exceptions" enforcement? I say it is:
  * In a correctly written program no precondition/postcondition (contract) or assetrion violations
    would ever be triggered. Any of these violations mean a bug in the program.
  * In a correctly written program THAT RUNS IN A PERFECT WORLD no exception would ever be thrown.
    There'll be no "database_exception"s to signal that the DB engine is down, no "bad_alloc"s to signal
    that we're out of free store, etc.
  * What I'm proposing is to specialise the handling of exceptions that can occur in a correctly written
    program running in an imperfect world. Can "io_exception" happen? Yes, due to a genuine CRC error.
    Can a "network_exception" happen? Yes, if the line is down. Can a "bad_cast" happen? Yes, if the program
    is badly written, so "bad_cast" should never be "checked".

So, to recapitulate, I would want, in a perfect world, for the C++ to offer both programming-by-contract and
checked-exceptions; but the two have a different purpose:
  * P-B-C is a tool that can aid in program verification (at compile-(!) and run-time), while
  * If "exception handling" if a mechanism to make sure some errors "cannot be ignored", then "checked exceptions"
    is a tool to ensure some of these errors "cannot be ignored at compile time".

Just an example of when I may need both:
=========================================================================
class db_exception { ... };

class cursor { ... };

class database
{
public:
  cursor get_first_record(void * rec) throw(db_exeption)   // throws "db_exeption" on an I/O error
    require: rec != null;        // if, on entry, "rec" is "nullptr" we have a bug in the code
  { ... }

  bool get_next_record(cursor & c, void * rec) throw(db_exeption) // throws "db_exeption" on an I/O error
    require: c != null;           // if, on entry, "c" is "nullptr", it's a bug in the code
    require: rec != null;         // if, on entry, "rec" is "nullptr" we have a bug in the code
    ensure: (result == false) ||  // either the call failed...
            (old(c) > c);         // ...or, if it succeeded, the cursor has advanced
  { ... }
};
=========================================================================

Incedentally, if I could get the C++ community interested in a "programming-by-contract", I would also
consider myself happy - but that would require an extra syntax to the C++, which I have no chance of getting
past the C++ committees. Thirty-five years of practical experience with two dozen languages are, naturally,
no match for a bunch of well-meaning one-language experts.

Thanks again for your response, and especially for talking about programming-by-contract - I did not
dare to raise that subject in a C++ world for fear of being ridiculed.

    Andrey Kapustin

On Fri, Jun 26, 2020, at 22:12, andrei--- via Std-Proposals wrote:

Good morning,

You have, indeed, convinced me that the "int foo() throws(auto)" is a no-go and if it will never make it into the C++ language, the better for that; your few well-chosen examples have been informative.

However, I'm still adamand that C++ needs to allow both un-checked and checked exceptions for its practitioners, depending on their needs:

• If I'm a writer of a shared library heavy on templates, then I'll never use this weird new feature, and my code will always be a valid C++.
  
• If I'm a writer on a project where safety means all, I want checked exceptions even more than I want programming-by-contract.
  

After thinking about this for a few days I think this second statement is wrong: I think you want programing-by-contract with exceptions as one contract type. (post condition)  By making exceptions a contract you unify with another part of the language instead of needing new syntax - this alone makes it more likely you can get someplace with your want. Contracts also give you more/better options for what if the exception happens anyway. Without going with contracts, checked exceptions are all or nothing which means almost nobody will retrofit them: they niche that only a few will use and thus not worth adding to the standard. With contracts you can start adding checked exceptions incrementally with choices for how to find out you are wrong, and choices for how to handle being wrong.

I don't follow contracts closely (though I feel like I should), but I think joining them and improving their papers to address exceptions is a better step for you.