Change view_from_string to be more 2 phase name lookup friendly #612
+140
−82
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The original issue dates waaaaay back to issue #8 where
str_concatwas technically not two-phase-name-lookup clean since function overload sets only consider the functions that have been declared at the time of use, so all of the otherstr_raw_pointeroverloads should not be considered for overloads. So this is an issue I've been wanting to tackle for some time.When syncing with the OS, there was a conflict when calling
str_concatwith bothstd::filesystem::pathandwinrt::hstringsince both are implicitly convertible to bothstd::wstringandwil::zwstring_view. Since I need to address those errors, I figured I might as well tackle both.This changes it so that
view_from_stringdelegates out to a class template that can be specialized, which doesn't have the same problems as function overloads. The negative consequence is thatstr_concatcan no longer be used with types implicitly convertible tostd::wstring, however upon further inspection I only found one reliance on this and it was forstd::filesystem::path, and fixing that usage is goodness anyway since the implicit conversion makes a copy (calling.native()is better).Fixes #8