Just because an array has its size known at compile time, doesn't mean its contents are known at compile time. For instance if you declare a char[1024] and then read into it from a socket, that data is only knowable at runtime. And if you were to pass it into a function, sure, its size is known at compile time, but that's it without other constraints.

As for wanting to expand an array like `str...`, I can maybe see value in that, but it also seems to me like you could accomplish much the same thing if P1061 "Structured Bindings can introduce a Pack" were to be accepted into the standard, as then you could do e.g.

auto &[elems...] = my_array;
some_other_function(elems...);

And while that isn't exactly the same, it feels close enough for me. Plus even today you could use std::apply or similar to turn array elements into a pack.
------- Original Message -------
On Thursday, September 21st, 2023 at 6:55 PM, Chris Gary via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Oops. I was hasty and just pasted " p1045" into google and accidentally clicked a link to the fmt library proposal (same idea anyway)...

URLs are helpful, since these don't always show up as expected.

This is an obvious problem, though its hard to say who is working on what (or what it ought to be called).

On Thu, Sep 21, 2023 at 5:50 PM Chris Gary <cgary512@gmail.com> wrote:
What I'm suggesting would be a generalization beyond strings.

Array of anything available at compile time?
It should be usable in a constant expression, albeit at whatever one-time cost it might incur there.

This induces a set of unique function invocations (at compile time), each invocation must be identified entirely by parameters values.
This is also implied by p1045. If unpacking array contents into non-type template parameters were possible, the effect would be the same.

To emulate concrete ODR in this idea of constexpr, a "function pointer" would symbolically refer to the set of all invocations of functions matching a specific signature, restricted to the subset induced by its target. Deducing which concrete implementation to which it points happens in a different stage anyway.

In essence, all things are variables. Template instantiations can be seen as function invocations with combinations of type and non-type arguments. If necessary, a constexpr function invocation and result at compile time can be uniquely identified by the values of its arguments and all static data referenced. I believe the same concept is applied in memoization, and I do the same thing mentally when organizing metaprograms.


On Thu, Sep 21, 2023 at 5:20 PM Giuseppe D'Angelo via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Il 21/09/23 21:12, Chris Gary via Std-Proposals ha scritto:
>
> template< std::size_t size_ >
> constexpr char only_constexpr_example( const char (&str)[size_] ) noexcept
> {
> // In a constexpr context, the size and contents of str are "known".
>
> // Really no different than a numeric UD-literal.
> //
> // This declaration makes the function constexpr-only
> // since it requires knowledge of str's contents at compile time.
> using chars = char_list< str... >;
>
> // If the size of an array is known, this can be the
> // same as an element-by-element copy construction
> // at runtime.
> constexpr char str2[]{ str... };
>
> return str2[0];
> }`

This sounds akin to constexpr function parameters (p1045).

My 2 c,

--
Giuseppe D'Angelo

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