Hi everybody,

> Unfortunately, that clear, reasonable design is being replaced, bit by
> bit. They're now becoming an expedient way to make small lists of
> numbers as if they were literals. Of course, the fact that
> braced-init-lists still are not expressions keeps forcing these
> `initializer_list` hack-fixes onto things instead of finally sitting
> down and deciding what exactly this grammatical construct ought to be
> used for.

If you don't want to abuse std::initializer_list to create literal-like
lists of values, I wonder if using an array reference would do the
trick:

template<ranges::input_range R1, class V2, std::size_t N,
         class Pred = ranges::equal_to,
         class Proj1 = std::identity, class Proj2 = std::identity>
  requires std::indirectly_comparable<ranges::iterator_t<R1>, const V2*,
                                      Pred, Proj1, Proj2>
constexpr bool equal( R1&& r1, V2 const (&r2)[N], Pred pred = {},
                      Proj1 proj1 = {}, Proj2 proj2 = {});

The only drawback I can see here is that the compiler won't deduce the
type of the array from an empty initializer list, i.e. this won't
compile:

std::vector<int> v;
assert(std::ranges::equal(v, {}));

This is because the size of an array must be greater than 0.

The code above wouldn't compile with the overload proposed by Arthur
either, as the compiler doesn't know how to deduce V2. In that case,
however, you could default V2 to the value type of range r1.

What are your thoughts on this?

Il giorno mer 25 gen 2023 alle ore 13:15 Giuseppe D'Angelo via
Std-Proposals <std-proposals_at_[hidden]> ha scritto:

> Il 25/01/23 05:44, Jason McKesson via Std-Proposals ha scritto:
> > Unfortunately, that clear, reasonable design is being replaced, bit by
> > bit. They're now becoming an expedient way to make small lists of
> > numbers as if they were literals. Of course, the fact that
> > braced-init-lists*still* are not expressions keeps forcing these
> > `initializer_list` hack-fixes onto things instead of finally sitting
> > down and deciding what exactly this grammatical construct ought to be
> > used for.
>
> Sure, I should not have used "datatype".
>
> The point is that at the moment they're a grammar construct that does
> some things. But it has also cannibalized a very convenient syntax;
> people will always push for having a convenient syntax over some overly
> stringent semantic requirements (as much as these requirements make
> sense in the broader context of the C++ language design). That's my
> motivation behind P2248 (I want to be able to write
> `find(vector_of_points, {1,2}`), and I guess the motivation behind
> similar proposals (Arthur's idea, P2218, possibly more...).
>
> I'm not sure how to solve the conundrum here; in the past some people
> entertained the idea of "user-defined brace list literals", which would
> still be not as convenient as writing {1,2,3} when one needs a list but
> maybe not very far off. That will solve the problem... in a few years.
> Today, even something as simple as
> template <class T, size_t N> using L = std::array<T,N>;
> and then writing `L{1,2,3}` still requires C++20 (!).
>
> My 2 c,
> --
> Giuseppe D'Angelo | giuseppe.dangelo_at_[hidden] | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>