On Tue, 15 Oct 2019, 04:35 Lyberta via Std-Proposals, <
std-proposals_at_[hidden]> 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).