errata :

(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)
>

Le ven. 3 déc. 2021 à 01:23, Jean-Baptiste Vallon Hoarau <
jeanbaptiste.vallon_at_[hidden]> a écrit :

> 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
>