On 07/10/2021 19.19, Tom Honermann via Liaison wrote:
> On 10/7/21 12:31 PM, Gabriel Dos Reis wrote:
>> [Tom]
>>> Thank you, Gaby, but I'm still a little confused. Could you please
>>> elaborate with regard to what runtime semantics you believe would
>>> differ?
>> See the conversion/promotion rules - I think they were points 2, 3, and 4 on the slide presentations.
> The polls we took had consensus for aligning behavior there (the only
> exception I'm aware of being that some conversions would be ill-formed
> in C++, but not in C).
>>
>>> What changes would be needed to align the runtime semantics across the languages?
>> The rules that the WG14 representatives were unwilling to make. See the poll results.
> Unless I'm mistaken, the only difference that remains after the polls is
> not a run-time concern. If that doesn't match your understanding, please
> be specific with regard to what semantic differences you believe remain.
>>
>> Note: I am quite happy with the C++ proposal, EXCEPT the aliasing part. I would reconsider my vote and recommendations to the various constituents when there is sufficient convergence. I would still recommend against the _Fxxx names in the global namespace.

Given that C doesn't want to change its conversion rules,
I understand that to mean that C++ needs to adopt C's
conversion rules for the new types.

Is there any other area you're concerned about?

What is the end-user story when writing new-style
floating-point code to be shared between C and C++?
What's the syntax, what minimum amount of #ifdef's
are required?

> There is a trade off between not polluting the global namespace in the
> standard vs programmers having to #ifdef their C code that is otherwise
> written in a common subset of the two languages. From the programmer
> perspective, the desired choice seems obvious to me, especially since,
> in practice, some implementations will just use the _Fxxx names anyway.

A possible balance would be to make _Float32 a typedef in the
global namespace when #including <math.h> (for C++).

> Perhaps worth noting, if the proposal included new suffixes for
> literals, then the aliases could be portably defined with something like
>
> using float32_t = decltype(1.0F32);

Assuming C++ wants to pursue a pure-library approach here, note
that literal operators are namespace-sensitive. Either this
needs a "using namespace std::whatever" in user code or they
need to be declared in the global namespace.

Or we make those suffixes first-class core language citizens.

Jens