You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, reflectable<T> exists. However, its name is somewhat misleading. If a class has a meta<T> specialization, for instance, reflect<T> is safe to be called on the type. However, reflectable<T> specifically excludes glaze_object_t<T>, which will be true if a class has a specialized meta<T>.
If a developer knows about this, it's an inconvenience. Cases like to<JSON, T> have to check for both reflectable<T> and glaze_object_t<T>. If a developer doesn't know about this, it's way worse, as they will think they're catching all the relevant types with requires reflectable<T>, but are actually missing all the types that have a meta<T> specialization.
Assuming reflectable<T> can't be renamed since it might break others' code, I propose adding a has_reflect<T> concept and using that internally, as an example other devs can follow.
The text was updated successfully, but these errors were encountered:
Currently,
reflectable<T>
exists. However, its name is somewhat misleading. If a class has ameta<T>
specialization, for instance,reflect<T>
is safe to be called on the type. However,reflectable<T>
specifically excludesglaze_object_t<T>
, which will be true if a class has a specializedmeta<T>
.If a developer knows about this, it's an inconvenience. Cases like
to<JSON, T>
have to check for bothreflectable<T>
andglaze_object_t<T>
. If a developer doesn't know about this, it's way worse, as they will think they're catching all the relevant types withrequires reflectable<T>
, but are actually missing all the types that have ameta<T>
specialization.Assuming
reflectable<T>
can't be renamed since it might break others' code, I propose adding ahas_reflect<T>
concept and using that internally, as an example other devs can follow.The text was updated successfully, but these errors were encountered: