On 10/8/21 1:56 AM, Jens Maurer wrote:
> On 08/10/2021 00.06, Tom Honermann wrote:
>> On 10/7/21 3:38 PM, Jens Maurer wrote:
>>> 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),
> C++ does not prevent narrowing conversions for existing types,
> except in {} contexts, so I don't know which consistency you're
> talking about.
>
> float = (double)1.0; // ok in C and C++
There is also [expr.const]p10 <http://eel.is/c++draft/expr.const#10>
concerning converted constant expressions, but otherwise yes, I don't
know of any differences where the languages actually overlap.
>
>> but that the well-formed cases would behave the same in
>> both languages. Is that a correct understanding of the poll results?
> That's my understanding of the intent.

Excellent. That suggests to me that there is some misunderstanding
between us and Gaby as there does not appear to be any (intended)
semantic differences for these types between the C and C++ proposals
that would affect run-time behavior.

Perhaps some clarification and a re-poll is in order.

>
>>>> 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.
> Currently, P1467R5 proposes treatment of f32 etc. suffixes
> as user-defined literals

Indeed. This strikes me as an unnecessary divergence between the languages.

Tom.