>
> Maybe that information can be hoisted into the function's metadata,
> inducing a set of functions based on their parameters?
>
> Admittedly, the binding criteria are complicated.
>
> More concretely (somewhat),
>
> read this:
> `constexpr auto q = 123456.789_qq;`
>
> like this:
> `constexpr auto q = operator ""_qq( "123456.789", 10u );`
>
> or, closer to what I mean:
>
> `constexpr auto q = operator ""_qq( "123456.789" );`
>
> where the definition is:
>
> `template< std::size_t size_ >
> constexpr mp_rational operator ""_qq( const char (&lit)[size_] )
> requires( std::is_constant_evaluated() ? matches_std_numeric_literal( lit
> ) : true )
> {
> if( std::is_constant_evaluated() )
> {
> using MQQ = materialize_qq_from_static_literal< lit... >;
> }
> else
> {
> if( ! matches_std_numeric_literal( lit ) )
> {
> throw std::invalid_argument{};
> }
>
> // etc...
> }
> }`
>
> loosely speaking.
>
> Template instantiations and static function invocations given known
> parameters can be viewed uniformly as unique "types". This is already
> known, since constexpr functions can be used to instantiate templates (e.g.
> a non-type parameter is identified by its constructor arguments).
>
> So, an alternative assuming something like constexpr static would work
> intuitively:
>
> `template< typename CodeUnitT, std::size_t size_ >
> constexpr mp_rational operator ""_qq( const CodeUnitT (&lit)[size_] )
> requires( std::is_constant_evaluated() ? matches_std_numeric_literal( lit
> ) : true )
> {
> // At compile-time: The requires clause is evaluated, raising errors
> wherever
> // the data can be examined directly.
> //
> // At runtime: Throws an exception if lit violates whats in the
> requires() clause above.
> return materialize_qq_from_static_literal_as_fn( lit ).bind();
> }`
>
> Reflecting on this, what I'm really after is just materializing ordinary
> data from compile time into static data...
>
> To my original point, being able to expand arrays into other arrays (or
> function parameter lists) seems obvious to me.
>