-
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
<algorithm>
: ranges::find()
rejects some sentinels due to iterator unwrapping
#2591
Comments
Urgh, That is a nasty one and I am really close to saying. Screw that and use a proper ranges facility like Long story short, this does affects all ranges algorithms. We would need to introduce a new helper that checks both template<input_iterator _It, sentinel_for<_It> _Se>
iter_sentinel_result_t _Get_unwrapped(_It _First, _Se _Last) const noexcept {
if constexpr(sentinel_for<decltype(_Get_unwrapped(_STD declval<_It>()), _Get_unwrapped(_STD decltype<_Se>())>) {
return { _Get_unwrapped(_STD move(_First)), _Get_unwrapped(_STD move(_Last)) };
} else {
return { _STD move(_First), _STD move(_Last) };
}
} @CaseyCarter does that fit? |
It's close. We are forbidden to "duck type" by throwing arbitrary expressions at user types to see what works. If a user passes a custom sentinel and a standard library iterator to an algorithm we're well within our rights to evaluate (Yes, we can make |
Fixed by #3024 |
Reported by Bjarne Stroustrup. Repros with VS 2022 17.2 Preview 1.
Click to expand lengthy compiler output.
The problem appears to be that
ranges::find()
takesinput_iterator _It, sentinel_for<_It> _Se
which thisIter, Sentinel
pair satisfies, but then unwraps them:STL/stl/inc/xutility
Lines 5279 to 5284 in ff54450
_Find_unchecked()
also takesinput_iterator _It, sentinel_for<_It> _Se
, but these are unwrapped: 🙀STL/stl/inc/xutility
Lines 5227 to 5229 in ff54450
Although we could compare
Iter == Sentinel
, we can't compareint* == Sentinel
, so this fails to compile (with an accurate but unhelpful warning in MSVC; Clang's error is lengthy but explains the chain of events clearly).We need to do something different here, although I'm not immediately sure what. (Unwrapping only when the unwrapped types would satisfy
sentinel_for
could be a solution.)This problem may also be extremely widespread throughout the range algorithms - marking as high priority unless we determine that this is an isolated obscure issue.
The text was updated successfully, but these errors were encountered: