Date: Thu, 21 Sep 2023 17:55:54 -0600
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
>>
>
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
>>
>
Received on 2023-09-21 23:56:06