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

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

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

Jens