There is also static_assert for compile-time invariant. Alex has some very specific requirements about wording the descriptions there.

It would be useful to mention what "report" means: where, how, and what does it look like for each of these cases?

Also, IIRC Alex had a definition of "invariant" that did not quite line up with C/C++ standard definition of the terminology. I came away from the Must() vs Assure() discussion thinking there was a disjoint paradigm in play.

I welcome this attempt at documenting error handling and invariant checking guidelines. Related code is often problematic, and documentation can help reduce the number of problems and correction overheads.

It's more than this. Coding Guidelines can (and should) feed LLMs, both code-writing and code-reviewing ones.

There is at least one bug and several problematic statements in the current version. It is also very difficult to derive the correct decision making algorithm from the proposed sentences. As Amos has noted, it is probably best to cover static_assert cases here as well.

I will find the time to rewrite this. I do not recommend making changes until then.

Feel free to improve

Francesco: Feel free to improve

@kinkie, I found my notes and started working on porting them here, but I will need to find more time.

P.S. I am not allowed to push to your branch.

Francesco: Feel free to improve

@kinkie, I found my notes and started working on porting them here, but I will need to find more time.

Thanks!
It's not urgent, take your time.

P.S. I am not allowed to push to your branch.

Can you now? I've added committers as maintainers for this repository

P.S. I am not allowed to push to your branch.

Can you now? I've added committers as maintainers for this repository

No, I cannot.

remote: error: GH006: Protected branch update failed for refs/heads/coding-guidelines-error-reporting.
remote: 
remote: - Changes must be made through a pull request.

Initially, I thought that you needed to follow GitHub instructions, but I now realize that there is another/bigger problem here: You have created a pull request branch in the official repository instead of using your own repository.

My recommendation is to keep this PR "as is" for now. I will post an alternative PR that starts with your changes. It will use an unofficial branch, of course. If that PR looks promising, we will close this PR and delete its official branch while collaborating on that alternative PR.

nitially, I thought that you needed to follow GitHub instructions, but I now realize that there is another/bigger problem here: You have created a pull request branch in the official repository instead of using your own repository.

I have used Github's "edit" feature. Unless I did something wrong, I suppose that the feature may not be good for us

I will post an alternative PR that starts with your changes

Sounds good, thanks.

I now realize that there is another/bigger problem here: You have created a pull request branch in the official repository instead of using your own repository.

I have used Github's "edit" feature. Unless I did something wrong, I suppose that the feature may not be good for us

You are probably right. I have not checked, but I suspect that:

1. GitHub's "edit feature" should not be used on the official repository. It is wrong to create temporary/PR branches here, essentially abusing your write privileges.

2. GitHub's "edit feature" may be used on your fork of the official repository. I do not know how easy it would be to generate a pull request against the official repository after such GitHub-UI-brokered edits, but I am pretty sure it would be easy (because it is easy to do when creating/editing branches in a forked repository the "old school" or "git" way).

The ball is on my side to post that "alternative PR that starts with your changes".

The ball is on my side to post that "alternative PR that starts with your changes".

Done at #50.