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
:)


> 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
>