[libcxx-commits] [libcxx] [libc++] Document the strengthened noexcept convention (PR #203869)

[Nikolas Klauser via libcxx-commits]

philnik777 wrote:

TL;DR I'm not convinced the comment gives me enough information (especially that I'd trust) to be meaningful to outweigh the cost.

> I actually think that having an easy way to check whether we stick to the standard or differ from it is quite valuable. As a matter of fact, this came up in a WG21 discussion last week, that's why I decided to tackle this.

That can easily be checked via libc++-specific checks, no?



> Well, once you know that something is strengthened, the task of figuring out in which ways it is strengthened is a lot easier than figuring out whether there's a diff from the standard in the first place. The point here is to call out places where we differ from the spec.

In what scenario do we care about this though? Once a lifetime during a discussion on when WG21 should add `noexcept`? (I assume that's where this came up.)



> Sometimes I like comment is the easiest way of documenting something. A unit test is useful to lock down the behaviour but that doesn’t stop the inline documentation from being useful

That assumes the inline documentation is correct and up-to-date, which it all too often isn't. I don't think I'd trust the comments if I ever actually needed to know for some reason, just like I never trust our synopsis comments. Also noteworthy is that the absence of such a comment doesn't tell me that a `noexcept` is actually not strengthened.

> > since they don't tell me how the `noexcept` is strengthened.
> 
> It's rarely meaningful to tell how the `noexcept` is strengthened. Exception specifications are almost always strengthened from "nothing" (implicit `noexcept(false)`) to `noexcept` or `noexcept(Cond)`.
> 
> The only meaningful cases I know are exception specifications relying on `allocator_traits<A>::propagate_on_container_swap::value` in the standard. We seem to be allowed to strengthen them to unconditional `noexcept` (if not, there should certainly be an LWG issue), and MSVC STL is already doing this.

I don't really know what point you're trying to make? The qualifiers you've added clearly mean that you can't assume there wasn't already something specified in the standard, so I do think it's meaningful to say how we strengthened the `noexcept`.



> I would either:
> 
>     1. Remove the `NoexceptPolicy` document in favour of the bit I'm adding to the coding guidelines, or
> 
>     2. Rephrase `NoexceptPolicy` to weaken it, and merge the notes about `// strengthened` into that document
> 
> 
> Any preferences?

I think I'd be happy to make it part of the guidelines. Whatever we settle on, it will be a general guideline to be applied throughout the code base.

https://github.com/llvm/llvm-project/pull/203869