C++ Logo

std-proposals

Advanced search

Re: [std-proposals] std::ranges::equal(v, {1,2,3,4,5})

From: Marcin Jaczewski <marcinjaczewski86_at_[hidden]>
Date: Wed, 25 Jan 2023 10:35:00 +0100
śr., 25 sty 2023 o 05:45 Jason McKesson via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On Tue, Jan 24, 2023 at 9:07 PM Giuseppe D'Angelo via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> > It's a bit unfortunate that braced lists are still a weird datatype.
>
> They aren't *supposed* to be a datatype. Braced-init-lists,
> grammatically speaking, aren't even *expressions*.
>
> They were supposed to have one job: to initialize objects. As a
> grammatical construct, that's all they do. The `initializer_list` type
> was introduced as a way to provide user-defined initialization of
> objects that take sequences of values.
>
> 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.
>
> It hasn't quite gotten as bad as lambda abuse has gotten, but every
> standard library function that gets an `initializer_list` overload
> when it *isn't* initializing a container is just one more step in that
> process.

Why not use `std::array{1, 2, 3}`? a bit more typing but all these problems
are avoided. And even have better move handling than init list.

> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2023-01-25 09:35:12