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 29/06/2020 14:49, Henry Miller via Std-Proposals wrote:
>
>
>
>
> 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.
>
>