On Tue, 2025-03-04 at 12:44 -0500, Arthur O'Dwyer wrote:
> On Tue, Mar 4, 2025 at 10:01 AM Avi Kivity via Std-Proposals <std-
> proposals_at_[hidden]> wrote:
> > C++ has a literal range type: std::initializer_list. However, its
> > elements are const and so initializing a container from the
> > elements involves a copy.
> > I propose std::ranges::literal<T>, constructed from
> > std::convertible_to<T>....
> >
>
>
> Nit: This really has nothing to do with `ranges`.
>

I was fooled by the fact that I want to use it to create ranges of
literal objects.


> The state of the art is well covered by Jason Turner's C++Now talk
> from 7 years ago:
> https://www.youtube.com/watch?v=sSlmmZMFsXQ
> He covers some alternatives such as
> template<class... Elts> explicit vector(std::in_place_t,
> Elts&&... elts); // informally proposed by Simon Brand
> and
> template<size_t N> vector(std::array<value_type, N>&& elts);
>
> Your proposal,
> auto v = std::vector<big>(std::from_range,
> std::ranges::literal<big>(big(7), big(3), big(9)));
> looks to do the same thing as, but have a heavier-weight spelling
> than, Simon Brand's simpler
> auto v = std::vector<big>(std::in_place, std::array{big(7), big(3),
> big(9)});
>


Acknowledged, but it's also more flexible, as you can use it to seed
any range computation, not just container initialization.


> Jason suggests adding "some kind of movable_initializer_list". This
> has been proposed by Rodrigo Castro Campos in 2008
> (mutable_initializer_list<T>):
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2719.pdf
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2801.pdf
> and again by David Krauss in 2014–2015 (own_initializer_list<T>):
> https://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4166.pdf
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0065r0.pdf
>
> > If all constructor parameters are rvalues, then the range produces
> > rvalues too.
> >
>
>
> What if some constructor arguments aren't rvalues? It'd have to be
> ill-formed then, right?

No.

> At any rate, you can't have the return type of
> `ranges::literal<T>::iterator::operator*()` dynamically depend on how
> the `ranges::literal<T>` object was constructed.
>

Why not? If ranges::literal<T> is a function object, different
overloads of literal::operator() will be called, resulting in different
return value types.



> One might say, "Why not just have the compiler turn {rvalue, rvalue,
> rvalue} into a movable_initializer_list instead of an
> initializer_list, automatically?"
> But the problem there is that the vast majority of initializer-lists
> consist of prvalues! Consider:
> std::vector<int> v = {1, 2, 3};
> It would be a bad thing if this line constructed a
> movable_initializer_list<int> on the stack, permitted the vector to
> move-out-of its elements, and then had to clean up the moved-from
> remnants.
> What we want is for this line to construct an initializer_list<int>
> to an immutable array {1,2,3} in static storage (.rodata). And in
> fact that's what we get, since P2752 was DR'ed.
> Here's GCC's codegen. Clang trunk still refuses to implement P2752.
> https://godbolt.org/z/Wj575fz4z
>
> So there's a tension here: We would like the compiler to "just give
> me move semantics" when necessary (e.g. with an initializer-list of
> unique_ptrs, or an initializer-list of runtime-valued std::strings),
> but at the same time we'd like the compiler to give us a nice read-
> only view over a static data array whenever that would be better.
> That decision certainly isn't something that can be made by any
> paper-standard-friendly heuristic; it must be left to the
> implementation.
>
> Executive summary: This is a real, well-known, problem; but I think
> your suggested solution of just adding something-like-
> movable_initializer_list (and leaving it up to the programmer to
> decide when to manually apply that heavyweight syntax) is
> insufficient. A suitable proposal in this area should be able to
> compile
> std::vector<std::unique_ptr<int>> v = { std::make_unique<int>(1),
> std::make_unique<int>(2) };
> right out of the box. If we aren't enabling people to write that,
> then we aren't really helping them.
>
> People can already write: https://godbolt.org/z/4WT1YGxeb
> std::vector<std::unique_ptr<int>> w(
> std::from_range,
> std::array{
> std::make_unique<int>(1),
> std::make_unique<int>(2),
> } | std::views::as_rvalue
> );

I think that's a viable alternative and retract the proposal. I didn't
consider it because I thought std::array uses std::initializer_list
which is rvalue poison, but it does not.


> so, anything that requires this general level of ceremony around it
> isn't worth the bother of standardizing. Simply replacing
> `std::array{...} | rv::as_rvalue` with `std::ranges::literal{...}`
> doesn't rise to the occasion.
>
> –Arthur