On Thursday, March 6th, 2025 at 10:43 AM, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> wrote:

> On Tue, Mar 4, 2025 at 3:03 PM Zhihao Yuan <zy_at_[hidden]> wrote:
>

> > If someone is designing their own container,
> > a simple rvalue reference to array is usually
> > enough
> >

> > template<size_t N>
> > vector(T (&&arr)[N]);
> >

> > // use
> > vector v1({2, 4});
> > vector v2({std::make_unique<int>(1), std::make_unique<int>(2)});
> >

> >

> > https://godbolt.org/z/4fbYc37n6
>

>

> I would be skeptical of that, though.
> (1) That disables the "normal" way of constructing from a bag of elements:
> vector v1 = {2, 4}; // no longer works


We are used to it, but you already know the pitfalls.
vector v1 = {a.begin(), a.end()};


> (2) That disables P2752 static-storage optimization:
> https://godbolt.org/z/sTnqqaove
> vector v1({
> #embed "large-file.dat" // compiles, but blows your stack at runtime
> });
>

> [...] In fact I recall you had opinions of some kind about applying P2752 to array literals too, which I shot down as scope creep; do you think it's possible to fix the codegen in #2 with a core-language change? The problem I see is that you're explicitly wanting to move-out-of the elements of `arr`, so it can't possibly go into static storage, right?
>



Yes and no. If a class knew the input is not meant
for modification, a matrix for example, then it can
take T const (&&arr)[N], in which case the
semantics is identical to initializer_list, i.e., binding
a unique reference to a backing array and implying
that the data is immutable. And then a generic
container can choose whether to add `const`
programmatically, if that's what they want

https://godbolt.org/z/K84GzP8Kr

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________