Hi Arthur,

On Nov 4, 2020, at 10:46 AM, Arthur O'Dwyer via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> 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_at_[hidden]<mailto: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 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_at_[hidden]<mailto:Std-Proposals_at_lists.isocpp.org>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

----
Luke D’Alessandro, Ph.D.
Department of Intelligent Systems Engineering
Indiana University Bloomington
ldalessa_at_[hidden]<mailto:ldalessa_at_iu.edu>