[intro.object] The template parameter object of type `const std::array<T, 0>` seems to be conditionally potentially non-unique

[frederick-vs-ja]

std::meta::reflect_constant_array sometimes reflects the template parameter object of type const std::array<T, 0> initialized with {}. Such an object can also be introduced by other language constructs.

Such a template parameter object can also be introduced by other constructs, and we don't say it is potentially non-unique in these cases. So it seems that given the following example:

#include <array>

template<std::array<int, 0> A>
constexpr bool f() {
  std::initializer_list<std::array<int, 0>> il{{}};
  return &A != il.begin();
}
static_assert(f<{}>());

Whether it's guaranteed to be well-formed depends on whether the template parameter object has been reflected by std::meta::reflect_constant_array.

Not sure whether this needs a CWG/LWG issue because the current specification is still implementable (since an implementation can always treat the template parameter object unique). But the wording seemingly indicates some weird status.

[jensmaurer]

In general, template parameter objects that are template-argument-equivalent are intended to be unique. What do you feel is missing in the specification? An LWG utterance that all std::array template parameter objects with size 0 are template-argument equivalent?

[frederick-vs-ja]

What do you feel is missing in the specification?

Hmm, I guess it would be better to clarify that only the built-in arrays reflected by reflect_constant_array/reflect_constant_string are considered introduced by them, while the const std::array<T, 0> objects are not.

[jensmaurer]

Note that "A" is a template parameter object in the above example, but the elements of "il" are not.

And I'm still not seeing the problem. A program may have a (unique) template parameter object of type std::array<int, 0> (and reflect_constant_array can return a reflection of such), but there can also be other (distinct) objects of type std::array<int, 0> in the program, too.

Can you amend your example to actually show a use of reflect_constant_array that would change something?
Can you point to a particular part of the specification that is troublesome here?

[frederick-vs-ja]

I think the following example can demonstrate the theoretical issue.

#include <array>
#include <meta>

constexpr std::initializer_list<std::array<int, 0>> il{{}};

template<std::array<int, 0> A>
constexpr const std::array<int, 0>* template_parameter_object_address() {
  return &A;
}
static_assert(template_parameter_object_address<{}>() != il.begin()); // #1, conditionally guaranteed?

constexpr auto ra = std::meta::reflect_constant_array(std::initializer_list<int>{});
constexpr auto addr = &(std::meta::extract<const std::array<int, 0>&>(ra));
static_assert(template_parameter_object_address<{}>() == addr); // #2, guaranteed

static_assert(addr == il.begin()); // #3, possibly allowed?

Without using reflect_constant_array, the template parameter object for template argument value std::array<int, 0>{} is never potentially non-unique, so #1 is guaranteed to pass.

However, once reflect_constant_array is used with an empty range of int, the template parameter object seems to be also introduced by reflect_constant_array, and then [intro.object]/9.3 seemingly makes it potentially non-unique.

[jensmaurer]

So, you're saying that we forgot to strike [intro.object] p9.3 when we changed reflect_constant_array to use "template parameter object" during wording review.

@katzdm , any opinion here? (And yes, that's a core issue, not an editorial one.)

[katzdm]

Striking p9.3 sounds right to me.

[brevzin]

I disagree. The point of 9.3 was, just like string literals, to allow implementations to reuse overlapping storage. That's obviously a non-issue for array<T, 0> which doesn't even have storage, and really array<T, 0> only needs to exist here because for some reason the Core language doesn't recognize T[0]?

But in any case, reflect_constant_string never produces an array<char, 0> because of the null-terminator. But for reflect_constant_array, we could just reduce to only referring to array objects — since I think that would be beneficial to hold onto. And there's a whole section of the paper which talks about overlapping, so let's not just remove it.