Is it intended to fully specify the shape of the names of node and slice types?

[frederick-vs-ja]

Currently, the node and slice types are specified as class templates (or more precisely, class template specializations), namely basic_json_node, basic_json_slice, and basic_const_json_slice.

It's unclear to me whether it's better to specify the shape of these type names. As per [namespace.std]/2, this will implicitly allow specializing these class templates if they get standardized. However, it's unlikely to meaningfully specialize them without specializing the associated basic_json.

If we make slice and node nested types with unspecified/exposition-only names, the slice types can be just implemented as nested class template template <bool IsConst> class slice_ {/* ... */};, which seems far less complicated than the current strategy.

CC @YexuanXiao.

[YexuanXiao]

This was intentional. Based on my thinking at the time, most interfaces always use json_slice instead of json, so having a separate name is a more direct way. There is similar reason for not using template parameters to distinguish whether it’s const, and intentional to let users differentiate between these two templates.

[frederick-vs-ja]

How about making slice and node types nested classes while providing convenient alias templates at the namespace scope?

[YexuanXiao]

How about making slice and node types nested classes while providing convenient alias templates at the namespace scope?

Sounds like there are no obstacles.