C++ Logo


Advanced search

Subject: Re: [std-proposals] std::to_array support for zero-length arrays
From: Arthur O'Dwyer (arthur.j.odwyer_at_[hidden])
Date: 2020-11-04 12:46:51

On Tue, Nov 3, 2020 at 11:01 PM D'Alessandro, Luke K via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Does this seem like something I should go ahead and put together
> officially?
> Consider that it is currently impossible, per [array.creation], to use
> std::to_array to create a zero-length array. We believe that this is merely
> an oversight, and not intentional.

It is certainly consistent, and *looks *intentional to me.

    auto i3 = std::to_array({1, 2, 3}); // OK
    auto d3 = std::to_array({1., 2., 3.}); // OK
    auto i1 = std::to_array({1}); // OK
    auto d1 = std::to_array({1.}); // OK

    auto i0 = std::to_array({}); // ill-formed for obvious reasons
    auto d0 = std::to_array({}); // ill-formed for obvious reasons

i0 and d0 can't *both *be well-formed. If you have an empty
braced-initializer-list, it's impossible to tell what the array element
type was intended to be.

If you're trying to use std::to_array with explicit template arguments, as
    auto f3 = std::to_array<float>({1, 2, 3});
    auto f0 = std::to_array<float>({});
then I think that usage needs justification (by which I actually mean, *that
usage is wrong*). Right now, in most cases, the standard library reserves
the right to replace
    template<class T, size_t N> auto to_array(T(&)[N]);
    template<size_t N, class T> auto to_array(T(&)[N]);
i.e. to alter "the number and order of deducible template parameters." When
a library function has deducible parameters, you should always *let them be

Why do you think you need this new overload? What use-case do you envision
for "std::arrays of maybe zero length" that wouldn't be better solved with
    auto fn = std::array<float, sizeof...(args)>{ args... };


STD-PROPOSALS list run by std-proposals-owner@lists.isocpp.org

Standard Proposals Archives on Google Groups