Hi,

Being able to create constexpr binding of non-trivial types seems useful
for reflection and metaprogramming. For example, for querying and storing a
name that is intended to be used during the runtime. This can be done (as
in the TS) with const char*, but 1/ this is not very ergonomic and 2/ does
this imply that every data resulting from a reflection query will be stored
in the binary of the TU, regardless of whether or not it's needed? (I think
it does). More generally, users might want to store dynamic arrays or
arbitrary structure in a constexpr binding. For dynamic arrays, there is
the ugly but fairly straightforward workaround of converting them to
std::array by performing the computation twice, first for getting the size,
secondly for loading the data into the std::array - ugly but doable, but
we're still limited to storing trivial types. For arbitrary structures this
can get quite difficult : for example how do I convert my AST structure as
a bunch of arrays of trivial types?

The current proposal (P1974) to resolve this is to introduce a new type
qualifier that introduces transitive constness.
I think it would be nice to explore other solutions : deep-constness in the
type system is great, however (i suspect) it will be a lot of work to
specify, and the resulting ergonomy, if I understand the proposal
correctly, is not ideal - the proposal consists in introducing transitive
constness only for a single branch of a type expression, thus the type for
the name of the reflection API would be something like
std::basic_string<propconst char>. Something that can be dealt with with
aliases, but I think it would be largely preferable to not introduce such a
schism between the types that can be used in a constexpr binding and types
that can't.

I would like to propose a rough draft for another solution :
Instead of extending the type system, introduce an attribute that certifies
deep-constness (let's call it [[deep_const]] or [[pure]]). A non-trivial
class can only be used as the type of a constexpr binding if it's annotated
with that attribute.

Any class C annotated with that attribute must satisfy these requirements :

1/ No public data members whose types are not deep-const

2/ All data members of pointers or reference type must have a deep-const
form

3/ Every member function (and friend functions, and the - possibly trivial
- special member functions) taking a "const& C" or "const&& C" must not
dereference, pass to another function, or return, a pointer or reference
subobject of C which is not in its deep-const form

4/ No mutable data member


(To make this more user friendly, I think the third constraint should not
be more of an opt-in behavior,

 where the compiler automatically insert the necessary implicit cast to
fulfill it)


A type is deep-const if it is :

* A const trivial type

* A const pointer, whose pointee is a deep-const type

* A const reference, whose referee is a deep-const type

* A const class/struct annotated with deep-const


The deep-const form of a type is defined by :

* DeepConst(T) = const T, defined if T is a deep-const type

* DeepConst(T&) = const T&, defined if T is a deep-const type

* DeepConst(T*) = const * DeepConst(T)


This essentially amounts to just lifting `deep-constness` out of the type
system and making it a trait.

The pros are :

* No extension to the type system, arguably easier to use and understand
than propconst
* no special types or qualifiers for constexpr bindings

* the most common containers in the standard library fullfill these
requirements already

The cons :

* ?

Curious to hear what you think and listen to other ideas in that space.

cheers,
-JB