[FR]: Make string matchers work with std::wstring_view

[brandl-muc]

Does the feature exist in the most recent commit?

AFAICT this feature is not contained in 85087857ad10bd407cd6ed2f52f7ea9752db621f which is currently the most recent commit.

Why do we need this feature?

Currently, StrEq(std::string_view{}) compiles but StrEq(std::wstring_view{}) does not. (note that the second call uses wstring_view)
Example on Compiler Explorer

Strictly speaking, this is rather a nuisance than a must-have feature, but the inconsistency is annoying at the very least.

Describe the proposal.

The simple fix would be to convert all wide string matchers to accept std::wstring_view instead of the current const std::wstring& str. This will support the aforementioned case and should also accept all cases that bound to const std::wstring &.

However, for narrow strings the implementation is more elaborate, allowing any single argument that can be used to construct a std::string:
gtest-matchers.h:808

template <typename T, typename = typename std::enable_if<
                          std::is_constructible<std::string, T>::value>::type>
using StringLike = T;

gmock-matchers.h:4783

template <typename T = std::string>
PolymorphicMatcher<internal::StrEqualityMatcher<std::string>> StrEq(
    const internal::StringLike<T>& str) {
  return MakePolymorphicMatcher(
      internal::StrEqualityMatcher<std::string>(std::string(str), true, true));
}

So probably, an anlogous implementation introducing a WStringLike type would be desired.

Is the feature specific to an operating system, compiler, or build system version?

This is standard C++17, but obviously, wstring is way more common on Windows.

[brandl-muc]

This is mildly related to #3829 support std::string_view for comparisons and #4876 [Documentation]: Clarify which string comparison macros support wide strings.

[brandl-muc]

Would a PR using the WStringLike approach be welcome?

[XAMeLeOH]

I have a different suggestions. Since in the main branch string_view's aren't wrapped into #ifdef's, I would replace the StringLike with ::std::basic_string_view. Then based on whatever character types are available, it can be string_view, wstring_view, u[8|16|32]string_view.
String views are constructable out of char *, basic_string, another string_view, so it seems to me that it's the way to go.
I'm also not a contributor, so it is really a suggestion.

[brandl-muc]

@XAMeLeOH I actually mentioned your suggestion as well. I believe the reason why that route was not taken is that it only supports std::basic_string_view (and types that are convertible to string_view). The route taken for narrow strings supports that and every other type from which a string can be constructed. That's probably not targeted at std::basic_string itself, only the constructor accepting an initializer list seems relevant, but rather user defined types that have a operator std::string() etc.

[XAMeLeOH]

Hey @brandl-muc! It turned out there is no easy way to do case insensitive comparison for pretty much anything besides ANSI (char) though it has been implemented for wchat_t which is an absolute blast I believe.

I drafted (#4926) the fix that should support string_views for wchar_t and other types of chars. Although case insensitive comparison had to be disabled for char[8|16|32]_t.

Please let me know what you think about it

[brandl-muc]

Sounds good and interesting.
But I'm just the bug reporter, not a maintainer. My opinion on the PR is probably of limited worth.

[XAMeLeOH]

My opinion on the PR

@brandl-muc I was more hoping that you would suggest adding more tests or alternative ways to tackle the issue :-) No worries though