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_at_[hidden]> 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_at_[hidden]> 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_at_[hidden]> 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_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals