Re: [lmi] Dealing with deleted operator<<() overloads for wide char types in C++20

[Greg Chicares]

On 3/2/21 2:13 PM, Vadim Zeitlin wrote:
> On Mon, 1 Mar 2021 21:59:59 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> On 2/26/21 12:29 AM, Vadim Zeitlin wrote:
> GC> > On Thu, 25 Feb 2021 22:35:34 +0000 Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
[...]
> GC> I'm not sure I follow. As you know, C++20 (N4861) says [6.8.1]:
> GC> 
> GC> | 11. Types bool, char, wchar_t, char8_t, char16_t, char32_t, and
> GC> | the signed and unsigned integer types are collectively called
> GC> | integral types. A synonym for integral type is integer type.
> GC> 
> GC> | 12. There are three floating-point types: float, double, and
> GC> | long double. ... Integral and floating-point types are
> GC> | collectively called arithmetic types.
> GC> 
> GC> Shouldn't the domain of bourn_cast<T,U> be all arithmetic types {T,U}?
> 
>  I don't think so, but we clearly disagree about it. To briefly define my
> position before attempting to defend it below, I think its domain should be
> all "normal arithmetic types" where the "normal" part means exactly "those
> for which it makes sense".

This is a case of 'ex falso quodlibet'. I would repair the
contradiction by abolishing the diabolic integer types:

> GC> I don't even know what these goofy types are supposed to be: maybe
> GC> UCS-2 and UCS-4, or something like that. But I don't see why the
> GC> motivation for their existence would need to be considered here:
> GC> they're arithmetic types, and isn't that all I need to know?

and you would repair it by redefining them as pseudointegral:

>  IMO it doesn't make much (or maybe any) sense to treat them as arithmetic
> types, even though they are defined as integral types in the standard. They
> are only ever useful as type of elements of an array representing a string
> in a particular encoding (UTF-{8,16,32} respectively) and they should be
> never used for anything else.

Here again, each of us grasps a different horn of the dilemma:

> GC> But maybe I misunderstand something. From my POV above,
> GC> integral types are integral types, and that's that, so
> GC> making some of them streamable and others not is lunacy.
> 
>  The fact is that these types are not streamable and there is nothing we
> can do about it. IMO it's just another reason to not group them with the
> "normal integral types".

but neither of us can convince the other by logical reasoning,
because any conclusion follows from a contradiction.

>  It's a valid point of view, but you can't correct this error. So I suggest
> working around it by introducing the concept of "normal arithmetic type"
> excluding char{8,16,32}_t. IMHO it's a more constructive way to look at
> things as they are.

Yet neither can you correct the error that the standard places
these diabolical integer types in the set of arithmetic types.
Both points of view are valid, but if you call yours "more
constructive", I can call mine "purer" as I would introduce
no novel concept.

If someday the standard declares that char16_t is no longer a
full-fledged arithmetic type, then on that day we'll agree
that it's outside the domain of bourn_cast.

Until then, it's still possible to discuss how to implement
LMI_TEST_EQUAL() so that it displays both unequal values on
assertion failure. We agree that it must be possible to
represent a char{16,32}_t value as a string for that purpose:

> [...] if we change anything here, I'd really like to use
> lmi_test::to_string() inside the macro in order to allow customizing the
> values appearance specifically for the test failure messages. Again, this
> is something that more or less all test frameworks do and there is a reason
> for it: it can be very useful to see just the _relevant_ parts of the
> values when the tests fail.

Is there an extremely simple and robust lmi_test::to_string()
implementation that you have in mind? If so, I wouldn't want
to dismiss it sight unseen.

I'll s/BOOST_TEST/LMI_TEST/ (or something more refined that that,
if appropriate), but at this time I don't want to add a lot to
this unit-test facility (e.g., bringing in lmi's value_cast<>()
with its colossal overhead), or replace it with a third-party
with a third-party library. I'd rather finish the currency-class
task, for instance.