On Wed, Mar 29, 2023 at 11:07 AM Jonathan Wakely <cxx_at_[hidden]> wrote:
>
> No. The English term still means the same thing. The standard defines terms
> **using English words** but within the scope of the C++ standard, they have
> the meaning ascribed to them by the standard. The standard defines what
> "argument" means. That doesn't mean I can't have an argument with clowns
> on the internet, it just means that **within the scope of C++** that word has a
> specific meaning, as defined by the standard.


At the beginning of a written contract, or on the first few pages of a
protocol specification, there are precise definitions given for some
of the terms that will be used later in the document. This isn't out
of the ordinary. These precise definitions are based on the simple
meaning of the English word, but are more specific to the topic being
discussed.

If I were to read the specification of the POP3 email protocol, and if
it were to read:
* recipient = the person sending the email
* sender = the person receiving the email

This would be rather strange. I mean the document can define terms
however it wants, but there should be some sense in how the terms are
based on the simple English words.

If the C++ Standard wants to separate integer types into two
categories, for example 'compact integer types' and 'oversized integer
types', then that's fine, I would like that distinction, because then
we could have 'uintmax_t' and 'uintmax_oversize_t'.

However if we're just going to say that some integer types are not
really integer types then that doesn't make sense. It's extremely
counter-intuitive for is_integral_v to be false for __uint128_t.