-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
join() forces const-ness on the range which prevents it accepting some range-v3 ranges #1784
Comments
Thanks for the suggestion. A PR to make the range requirements more compatible with ranges-v3 would be welcome. |
Thanks. I've submitted #1786 as you'll see above. BTW, I'm seeing various test failures in GCC and under sanitizers. Are these know issues or should I submit issues for them? |
Please submit an issue. |
vitaut
pushed a commit
that referenced
this issue
Jul 21, 2020
See #1784. Add tests that demonstrate the problem and check obvious variations.
Thanks. |
chenyt9
pushed a commit
to MotorolaMobilityLLC/external-fmtlib
that referenced
this issue
May 9, 2023
See fmtlib/fmt#1784. Add tests that demonstrate the problem and check obvious variations.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Thanks so much for all your fantastic work on fmt, standardisation and Tweeting.
The following attempt to combine range-v3 with fmt fails to compile under Clang or GCC (
-std=c++17 -fsyntax-only
) (Godbolt) :I'm pretty sure the problem is caused by the
const
s aroundformat.h:3388
. The range-v3 design involves some views (such asfilter
in the example above) updating internal state (eg a cached iterator) so they haveconst
-onlybegin()
/end()
, which means aconst
reference to such a view is not a valid range. See "View const-ness" on https://ericniebler.github.io/range-v3/ for more info.The text was updated successfully, but these errors were encountered: