Date: Thu, 21 Sep 2023 17:50:40 -0600
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
>
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:50:52