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

[Vadim Zeitlin]

On Thu, 25 Feb 2021 22:35:34 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2/25/21 8:55 PM, Vadim Zeitlin wrote:
GC> [...]
GC> > [in C++20] we can't insert
GC> > a char16_t value into the stream any more.
GC> > 
GC> >  There are several ways to solve this, but I wonder if it's even worth
GC> > solving it at all, or if we could simply remove test_same() calls for the
GC> > char{16,32}_t and wchar_t types in the test? It seems exceedingly unlikely
GC> > that bourn_cast() would be used with any of these types and, in fact, I
GC> > wonder if we shouldn't just prevent it from being used with them.
GC> 
GC> I'd like bourn_cast to work in every case where it could possibly make
GC> any sense--not excluding cases that are valid but seem unlikely--and
GC> likewise for its unit test.

 This is perfectly understandable, but IMO casting chars is exactly a case
which just doesn't make sense. You wouldn't, presumably, attempt to make
bourn_cast() work with strings, so why would you ever want to use it with
char{16,32}_t which can be exactly the same thing as UTF-8-encoded
multi-byte string?

GC> I'd be inclined to replace
GC>   INVOKE_BOOST_TEST_EQUAL(x, y, file, line);
GC> (only where it is actually problematic) with
GC>   INVOKE_BOOST_TEST(x == y, file, line);
GC> (I haven't tested that, but I'm sure something like it would work.
GC> The -"_EQUAL" macros are handy because on failure they print the two
GC> values that are unexpectedly unequal; but that handiness isn't very
GC> important for debugged code.)
GC> 
GC> Do you see a better way, or should I just make it so?

 I indeed think this would work, but doing it just for these types would be
a bit messy because we use it in a template function, so it'd require an
"if constexpr" (which is, of course, only a bit messy, compared to
SFINAE-level mess we'd have to use with pre-C++17 C++).

 It would also still leave us with the same problem in any other place
where we might use BOOST_TEST_EQUAL[*] with these types. So I was rather
thinking of implementing a complete solution for this by defining a
template lmi_test::to_string() function which would, by default, just use
operator<<(), but could be overloaded for some types, including both the
wide character types and any other types for which it could be useful to
have a different representation in the test assert failure output message
than in their normal operator<<() implementation (e.g. I'd definitely
appreciate seeing a more human-readable representation of calendar_date
here). This would, of course, require more changes, but I think it would be
worth it if we start changing anything here at all and I could do it, of
course.

 But my preference would still be to just forbid using bourn_cast() with
the wide char types as I remain convinced that this is an operation which
simply never makes sense.

 Please let me know what, if anything, should I do here.

 Thanks,
VZ

[*] We really, really ought to rename these macros to LMI_TEST_EQUAL() or
    something else not starting with BOOST_, pretending that they come from
    Boost is still confusing, even after all these years, and just imagine
    how puzzling it is to anybody new to lmi code base (I didn't have to
    imagine this when I saw Ilya being completely misled by their names
    relatively recently).

pgp_sTQqLIRpm.pgp
Description: PGP signature