-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
ranges::distance
fails to emulate the Standard's two overload presentation
#2987
Conversation
…ion of LWG-3664 By constraining itself with the union of the constraints of those two overloads. Test coverage is incoming in the LLVM update, against which I've verified the fix.
Is there a reason not to just do the two-overload version, given that the two-overload version is how the standard is written? |
There are exactly two reasons why an STL implementation would take advantage of as-if to do something differently from how it's phrased in the Standard: performance and throughput. This is the latter. We generally prefer |
I would agree with the latter point. If they took the same parameters, it would be different IMO, but doing this weird |
ranges::distance
needs to better emulate the two overload presentation of LWG-3664ranges::distance
fails to emulate the Standard's two overload presentation
Split into two overloads, reverified against the incoming libc++ test, and rewrote the commit message. |
903848d
to
9213ec0
Compare
Looks good to me. FYI @strega-nil-ms, I pushed a couple of comment changes after you approved. |
Thanks for finishing this up, @strega-nil-ms! |
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
Thanks for going the distance here! 🏃 🥇 😹 |
By not properly constraining itself with the union of the constraints of those two overloads. If we weren't trying to do something fancy just to avoid a bit of non-subsumption concept overloading, we wouldn't have written this bug in the first place. Let's split out into two overloads.
Test coverage is incoming in the LLVM update, against which I've verified the fix.
Merge conflict with #3024