[libcxx-commits] [PATCH] D142335: [libc++][ranges] Implement `ranges::to`.
Konstantin Varlamov via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Wed Jul 19 11:34:23 PDT 2023
var-const marked 13 inline comments as done.
var-const added inline comments.
================
Comment at: libcxx/include/__ranges/to.h:220-221
+ !is_volatile_v<_Container>, "The target container cannot be volatile-qualified, please remove the volatile");
+
+ return __range_adaptor_closure_t(std::__bind_back(__to_nondeduced<_Container>(), std::forward<_Args>(__args)...));
+}
----------------
ldionne wrote:
> Would it be reasonable to try using a lambda here? Something like
>
> ```
> auto __to_func = []<input_range _Range, class... _Args>(_Range&& __range, _Args&&... __args) -> _Container
> requires requires { ranges::to<_Container>(std::forward<_Range>(__range), std::forward<_Args>(__args)...) }
> { return ranges::to<_Container>(std::forward<_Range>(__range), std::forward<_Args>(__args)...); };
>
> return __range_adaptor_closure_t(std::__bind_back(__to_func, std::forward<_Args>(__args)...));
> ```
>
> It's more compact and a bit more localized. Your call.
I tried it out and I think I like it better (though it looks like `clang-format` has trouble with a constrained lambda).
================
Comment at: libcxx/include/__ranges/to.h:67-69
+template <class _Container, class _Range>
+concept __can_try_convert_without_recursion = !input_range<_Container> ||
+ convertible_to<range_reference_t<_Range>, range_value_t<_Container>>;
----------------
ldionne wrote:
> var-const wrote:
> > ldionne wrote:
> > > Maybe `__does_not_require_recursive_conversion`? Or `__try_non_recursive_conversion`? Or maybe just inline that in the function below and use an inline `requires`?
> > Went with `__try_non_recursive_conversion` (unless you feel strongly about inlining it).
> Re-reading it, I think it would be a lot more readable to inline, especially since there's an `else if` with the `input_range<_Container>` constraint.
Making this a concept is necessary to "short-circuit" the second condition (e.g. an `optional` satisfies the first condition, i.e., `!input_range`, but attempting to instantiate the second condition would fail since `range_value_t<optional<T>>` is ill-formed). Added a comment to that effect.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D142335/new/
https://reviews.llvm.org/D142335
More information about the libcxx-commits
mailing list