[libcxx-commits] [PATCH] D107396: [libcxx][ranges] Add `ranges::iota_view`.

[Tim Song via Phabricator via libcxx-commits]

tcanens added inline comments.


================
Comment at: libcxx/include/__ranges/iota_view.h:375-378
+  template<class _Start, class _Bound>
+    requires (!__integer_like<_Start> || !__integer_like<_Bound> ||
+              (__signed_integer_like<_Start> == __signed_integer_like<_Bound>))
+  iota_view(_Start, _Bound) -> iota_view<_Start, _Bound>;
----------------
ldionne wrote:
> Possible spec issue:
> 
> I'm kind of wondering why we don't define the constructor like this instead, and avoid defining a deduction guide altogether:
> 
> ```
> constexpr iota_view(W value, Bound bound) 
>     requires (!is-integer-like<W> || !is-integer-like<Bound> ||
>              (is-signed-integer-like<W> == is-signed-integer-like<Bound>));
> ```
> 
> As specified in the Standard, we have the following situation, which seems to be weird and inconsistent:
> 
> ```
> iota_view<signed, unsigned> view(x, y); // works
> iota_view view((signed)x, (unsigned)y); // doesn't work
> ```
> 
> I think both of them should not work.
> 
> @tcanens is that intentional?
This seems to me to be a "we'll protect you from accidentally shooting yourself in your foot, but not from intentionally pointing your gun at your foot and pulling the trigger" case. Mixing signs isn't inherently incorrect, so if people want to do it explicitly they can, but the deduction guide forces the type to be spelled out so that the mixedness is obvious.

It's more of an Eric/Casey question though.


================
Comment at: libcxx/test/std/ranges/range.factories/range.iota.view/sentinel/minus.pass.cpp:48
+
+// TODO: it seems odd that this is the *only* place we are required to have an input_or_output_iterator.
+// Example: https://godbolt.org/z/WGc9xoqcb
----------------
zoecarver wrote:
> @tcanens thoughts?
`sized_sentinel_for` has an opt-out, and any relaxation would need to both respect that and perhaps supply its own opt-out mechanism. That gets hairy pretty quickly and doesn't seem to be worth the extra complexity.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107396/new/

https://reviews.llvm.org/D107396