Thanks Zhihao,

On Nov 3, 2020, at 8:38 PM, Zhihao Yuan <> wrote:

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

On Tuesday, November 3, 2020 10:01 PM, D'Alessandro, Luke K via Std-Proposals <> wrote:

template <typename T>
constexpr array<T, 0> to_array(std::array<T, 0>);

I see no particular constraints on T in [], nor do any of the constructor traits appear to be relevant here, thus I have no preconditions and merely carried forward the is_array_v mandate from the existing overloads.

Since you get rationale and examples,
that fits in a small paper.

I slightly prefer a tag solution, because
array<T, 0> is not physically zero (or 1) size.

That’s interesting, I didn’t realize that the different implementations would present different sizes for this specialization. I have no problem with a tag type. I just wasn’t sure if there was an existing tag that might be appropriate (if monostate wasn’t in [variant] it would work), or how such a type would be introduced into the standard.

I’ll chose a class name and start working on something formal. I think I’ll probably put the tag class into [array.creation] and suggest changing its title from “Array creation functions” to “Array creation.” The alternative would be another section somewhere…?

Accepting one as an argument may have
some cost.  Another issue is that the type
array<T, 0> is public.  You don't mean to
allow people to do

  std::array<int, 0> a;

I did consider this, but it didn’t bother me. It wasn’t clear if this is actually something that [array.creation] is trying to avoid. I am concerned about the variance in sizeof(std::array<int, 0>) that I can already observe in current implementations, so it’s a moot point.

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

Luke D’Alessandro, Ph.D.
Department of Intelligent Systems Engineering
Indiana University Bloomington