On Tue, 15 Oct 2019, 04:35 Lyberta via Std-Proposals, <std-proposals@lists.isocpp.org> wrote:
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.

Then do what everyone else does and start with floatN and modify it from there. Granted, I know your naming extends from P1468, but that is one ugly naming scheme (itself derived from an existing emergent convention in literature that float64's natural extention should be called the arbitrary binary128 rather than float128). I have no idea why the word "binary" is used in the name of a float, but the word "float" isn't. Everything is binary. Eh well.

> 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.

And they should. They are more legitimate. The compiler knows best for the target machine. When it comes to communication, it's the human's job to coerce it into a different representation. The two are very different scenarios.

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.

std::floatN_iec559_t makes much more sense then.

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

No need to be so dramatic. The fundamental types are not broken, they're just flexible. They don't set specifics in stone because every platform is different, has different capabilities, efficient storage, access and calculation capabilities. A general purpose language needs that flexibility for typical situations but also needs to give the user control over representation when they have a specific reason (though there is most certainly work to be done on that front).