On Nov 4, 2020, at 11:54 AM, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]<mailto:arthur.j.odwyer_at_[hidden]>> wrote:

On Wed, Nov 4, 2020 at 2:22 PM D'Alessandro, Luke K <ldalessa_at_[hidden]<mailto:ldalessa_at_[hidden]>> wrote:
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:
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.

I do. :)
I see it mentioned once in p0325r4's examples (but never called out as a primary use-case), and zero times in the actual paper standard.

We must be looking at different versions of r4 then (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0325r4.html). It’s prominent in the introduction and appears a number of times in the impact on the standard.

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.

My impression is that std::to_array({args...}) is a drop-in replacement for std::experimental::make_array(args...). Neither std::to_array({}) nor std::experimental::make_array() works today — it can't deduce the element type `T`. Personally, I wouldn't call either of them with any number of explicit template arguments.

Regardless of what you would or wouldn’t do, std::experimental::make_array<int>() worked while std::to_array<int>({}) does not. You seem to feel this is a positive development, which is certainly a valid take. It’s anecdotally clear (cf. special callout in http://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p2081r1.html and paragraph in p0325r4) that make_array was removed as it was deemed redundant with array CTAD + to_array, but neither of them provides this previously-supported capability, which I was hoping to rectify.

Anyway, I would be mildly surprised if your code couldn't also benefit from the advice in
https://quuxplusone.github.io/blog/2020/08/06/array-size/ ;)

I’m not sure if this is snark or self promotion or an actual attempt to be helpful. Given the emoji I assume a bit of the first two, not much of the third.

[from blog]
Anyway, all of these options result in a lot of extra template instantiations, compared to plain old C-style arrays (which require zero template instantiations). Therefore I strongly prefer T[] over std::array<T, N>.

Indeed. I would much prefer to use a C array (+span as necessary) in my generic constexpr code, but the the context happens to sometimes be zero-length. I have considered (am strongly considering) enabling zero-length-array extensions as the alternative to std::array.


–Arthur

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