internal storage model in a future major version?

[FujiwaraNaoto]

Hi maintainers,

While reading through the discussion in #2865,
I was trying to better understand the design trade-offs behind
the current internal storage model of basic_json.

From what I understand, the current tagged-union–based storage
(with manual lifetime management) is carefully designed to prioritize:

• small object size
• ABI stability
• C++11 compatibility
• performance

I also found that a related idea was discussed very early on in #7,
where using std::unique_ptr internally was considered difficult
due to the use of unions and layout constraints.

Given those past considerations, I was wondering about a broader question:

If a future major version were to relax constraints such as
C++11 support and ABI compatibility, would it make sense to reconsider
the internal storage approach?

For example, possibilities might include:

• std::variant-based storage
• std::unique_ptr for heap-managed types
• potential integration with std::pmr

Possible advantages could be:

• simplified lifetime management
• clearer move semantics
• more straightforward exception-safety reasoning

At the same time, I fully recognize the trade-offs:

• increased sizeof(json)
• compile-time impact
• potential performance differences
• deviation from the current minimal layout philosophy

I am not proposing an immediate change.
Rather, I am curious whether such a redesign direction
has ever been discussed in the context of a future major release.

If this direction seems worth exploring,
I would be interested in looking into it further.

I may also be misunderstanding some of the original design constraints,
so any clarification would be greatly appreciated.

Thank you for your time and for maintaining this excellent library.

[nlohmann]

There is currently no plan to change the current storage model. Potentially, we can reduce the storage size by using pointer tagging and get rid of the type enum - but that's just a rough idea without any further investigation.