Arthur O'Dwyer:
> The paper's title is "Reserve good keywords for floating-point types." But
> `iec60559_binary16` (which I had to reopen the PDF twice to double-check
> the spelling of) is *100% absolutely not* a "good" keyword by *any*
> metric. So, the paper is currently mis-titled.

It was the most unambiguous name I could find. There are still many
floating point formats around. I would have proposed floatN but those
identifiers are widely used.

> I don't see any advantage to "reserving" these tokens for "future" use. Are
> you worried that if you don't reserve them now, somebody might use them as
> identifiers in real code? If that's your concern, then you should be
> equally concerned that someone might *already* have used them as
> identifiers in real code; in which case, you are proposing a breaking
> change, and you should say so.

There is an impact section. Otherwise I propose to solve the naming
problem of P1468 via this paper.

> Rather than use `iec60559_binary16` for the new keyword, I suggest you
> focus on using a keyword such as `__iec60559_binary16`, and then in
> whatever future proposal gives it semantics, you can also propose
>
> namespace std {
> using float16 = __iec60559_binary16;
> }

The problem is that in this case beginners will probably continue to use
float and double because they look more legit.

The guidelines then become:
Use std::[u]intN_t for integers.
Use bool for boolean.
Use std::byte for bytes.
Use std::floatN for floats.
Use charN_t for Unicode code units until better types become available.

Which means that most fundamental types should be avoided in modern
code. Do we want to live with language whose fundamental types are broken?