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

[Zoe Carver via Phabricator via libcxx-commits]

zoecarver marked 4 inline comments as done.
zoecarver 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>;
----------------
tcanens wrote:
> 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.
> 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.

This logic makes sense. I suppose that also explains why the deduction guide is here in the first place (and we don't just remove the `type_identity_t`s from the `_Start`/`_Bound` ctor). As always, thanks for interpreting the Standard for us :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107396