On 9/17/21 7:25 PM, David Olsen via Ext wrote:
> Jens Maurer wrote:
>
>>> Maybe one way out of the naming problem is to say that
>>> C++ retains its model that std::float16 (etc.) is an alias to
>>> an unnamed fundamental type plus say that the typedef _Float16
>>> is introduced in <cmath> and <math.h>, referring to that same type.
> I kind of like that idea. It might work. I will think it over some more and maybe incorporate it into P1467. Thanks for the suggestion.
>
> What do other people think about it?

I like this better than the status quo, but it still seems unnecessarily
complicated and still leads to tooling related problems.

Assume a tool that needs to consume headers provided by another
implementation (e.g., static analyzers like Coverity, doc tools like
Doxygen, etc...). If the types that std::float16 and _Float16 alias are
implementation defined, then these tools must be aware of the actual
names of these types in all of the implementations they strive to
emulate. That seems like unnecessary complication to me.

Granted, such tools necessarily must mimic various features of other
implementations since standard headers often use extensions of some
kind. But the more we can reduce such necessity, the more we reduce the
burden of writing such tools.

I strongly prefer that the types be given standard defined names (C++
can still provide aliases in the std namespace). Like others, I would
prefer they not be _Ugly names, but I strongly prefer _Ugly names over
implementation-defined names.

Tom.

>
>
> -----Original Message-----
> From: Ext <ext-bounces_at_[hidden]> On Behalf Of Jens Maurer via Ext
> Sent: Friday, September 17, 2021 6:22 AM
> To: Aaron Ballman <aaron_at_[hidden]>; Evolution Working Group mailing list <ext_at_[hidden]>
> Cc: Jens Maurer <Jens.Maurer_at_[hidden]>; SG6 numerics <sci_at_[hidden]>; Matthias Kretz <m.kretz_at_[hidden]>; WG14/WG21 liaison mailing list <liaison_at_[hidden]>
> Subject: Re: [isocpp-ext] [wg14/wg21 liaison] Report from the recent C/C++ liaison meeting (SG22); includes new floating point types(!)
>
>
> On 17/09/2021 13.56, Aaron Ballman wrote:
>> FWIW, it's sounding more and more to me like there's high risk for
>> user confusion and incompatibilities between C and C++ in this space
>> and we should consider a joint meeting with the C Floating Point Study
>> Group to see what can be done in both committees to reduce that
>> likelihood. I'm planning to discuss P1467 in SG22 on Oct 1, and I will
>> invite the CFP group (as well as others in WG14) to attend.
> Well, given the current scheduling, it is very likely that C
> just goes ahead with what they have (they've been working on
> it for years), and C++ won't do anything for C++23 due to timing
> constraints.
>
> Maybe one way out of the naming problem is to say that
> C++ retains its model that std::float16 (etc.) is an alias to
> an unnamed fundamental type plus say that the typedef _Float16
> is introduced in <cmath> and <math.h>, referring to that same type.
>
> This way, C code that uses _Float16 would just work if the code
> included <math.h>, which seems likely.
> Yet, we get away with not officially introducing _Ugly keywords
> in C++. And since a type name and an alias pointing to that type
> is indistinguishable in C++, compilers might just happen to treat
> _Float32 as a keyword instead of an alias.
>
> Jens
>
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2021/09/17675.php