On 10/7/21 3:38 PM, Jens Maurer wrote:
> 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.

For arithmetic conversions, yes, and there was weak consensus for that
in WG21 (but note that several attendees had to leave the telecon before
polls were conducted).

For implicit conversions, my understanding is that WG14 didn't want to
adopt the C++ rules that make narrowing conversions ill-formed (thus
maintaining consistency between differences in the languages for other
existing types), but that the well-formed cases would behave the same in
both languages. Is that a correct understanding of the poll results?

> 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++).
A typedef of what though? What I want to avoid is implementations having
different builtin names for these types.
>
>> 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.

I was imagining core language support; a UDL would still require a type
with a name that is not recognizable except by the library provider. The
decltype(0.1f32) approach works for me because it avoids the need for
the type to have a builtin name at all; like a lambda closure type.

I previously missed it in P1467R5 that there are literal suffixes
proposed for C2x. I think C++ should also adopt those suffixes directly;
not through the use of UDLs.

Tom.