On Nov 4, 2020, at 10:46 AM, Arthur O'Dwyer via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

This message was sent from a non-IU address. Please exercise caution when clicking links or opening attachments from external sources.

On Tue, Nov 3, 2020 at 11:01 PM D'Alessandro, Luke K via Std-Proposals <std-proposals@lists.isocpp.org> 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 in

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).

This is the use case that occurs with some frequency in real code, and is explicitly referenced numerous times in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0325r3.html. I don’t feel like it 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]);

with

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 deduced.

This is a potential problem that I wasn’t aware of, thank you for pointing it out. Given p0325r3 maybe it is necessary to update the standard to make this a case where the order is constrained?

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... };

?

Indeed, this is the current workaround we have implemented.

Perhaps my confusion is that to_array claims

An interesting consequence of this proposal is that we no longer need make_array.

I do not have any knowledge of the process that lead to the adoption of to_array and removal of make_array, however make_array _did_ support this usage and to_array does not without the overload.

Luke

–Arthur

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals