Hi Sophia,

the proposal got rejected in Jacksonville 2016.

There were lots of concerns regarding breaking brace-balancing with this proposal for the half open range syntax: [min..max). This seemed to have been a concern regarding tools, compilers and in general for programmers since they are not used to such syntax. Even though this syntax is known in mathematical context it was understood that this might not be so true for programmers.
A library based solution has the additional benefit of adding a name to the range generator allowing for a more clear expression of the programmers intent even if he/she or anyone who has to read the code is unfamiliar with the mathematical syntax. One possibility that came up was:

    for (auto i : index_range(0, 5))

Additionally ranges were on their way and many commitee members argued against a language solution and in favor of a library solution since it could be done already easily with ranges.

    Sebastian

Interesting, thanks Andrew.  Do you recall and would mind sharing the reasons for its rejection?

thanks,

Sophia

On Aug 29, 2019, at 10:21 AM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:

I plan to target C++23 with it.

I proposed a similar core language feature in 2016 in P0286:

    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0268r0.pdf

but the proposal was rejected.

On Fri, Aug 30, 2019 at 2:46 AM Sophia Poirier <spoirier@apple.com> wrote:

Thanks Andrew, that's a great collection of utilities.  Is that a proposal you are working towards submitting?  (I note it has no paper number.)

I do prefer to see it language level as I think it is intuitive as I have suggested, plus it is such a basic and fundamental logical operation (and allows serving those who cannot use the STL), however I do recognize there are fewer hurdles to landing library features.

- Sophia

On Aug 28, 2019, at 5:23 AM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:

See:

https://docs.google.com/document/d/1gBdBualdIU1bpgW_El4GT-p0he9Yr7D52xmLmHes5Qo/edit?usp=sharing

On Wed, Aug 28, 2019 at 3:42 AM Sophia Poirier via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

On Aug 27, 2019, at 10:26 AM, Barry Revzin <barry.revzin@gmail.com> wrote:

On Tue, Aug 27, 2019, 12:02 PM Sophia Poirier via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Thanks, yes I have that as an alternate example in my longer notes.  My understanding is that it still suffers from the type-matching problem as traditional for loops.  Your example of:

for (const auto i : std::views::iota(0, count))

only works when count is an int.  Otherwise, if for example count is uint32_t, it would need to be:

for (const auto i : std::views::iota(uint32_t{0}, count)

or:

for (const auto i : std::views::iota(0u, count))

or:

for (const auto i : std::views::iota<uint32_t>(0, count))

or:

for (const auto i : std::views::iota<decltype(count)>(0, count))

or something along those lines, or you will get template instantiation failure compiler error.  I think that if std::views::iota had a constructor overload that was simply the second argument (count) with implicit zero start, then it would be a good option.  However I believe there is interest to reserve such an overload perhaps for infinite ranges?

thanks,

Sophia

This is true. But we can write a helper function to get the correct type of 0 so we don't need the ugliness at point of use:

template <std::integral T>

auto upto(T n) {

    return views::iota(T{0}, n);

}

We end up with:

for (const auto i : upto(count))

Barry

This could be the basis of an alternate library proposal, true.

- Sophia