On Thu, Oct 7, 2021 at 4:03 PM JF Bastien <cxx_at_[hidden]> wrote:
>
>
>
> On Thu, Oct 7, 2021 at 12:38 PM Jens Maurer via Liaison <liaison_at_[hidden]> 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.
>
>
> Not necessarily. We'd need to understand the tradeoffs of one approach versus the other. I'd expect a discussion of this in the paper, to explain why specifically we're diverging from C. And maybe WG14 will be convinced :)

FWIW, WG14 would have to see that paper Very Soon in order to impact
C23 (after C23 ships, it will be harder to change in C due to the risk
of breaking code).

~Aaron

>
>>
>> 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
>>
>>
>> _______________________________________________
>> Liaison mailing list
>> Liaison_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
>> Link to this post: http://lists.isocpp.org/liaison/2021/10/0876.php