docs: Fix missing newline necessary in docs website

[mikomikotaishi]

• The changes are described in detail, both the what and why.
• If applicable, an existing issue is referenced.
• The Code coverage remained at 100%. A test case for every new line of code.
• If applicable, the documentation is updated.
• The source code is amalgamated by running make amalgamate.

In my previous PR, #5137, I didn't add a newline at the beginning of the bullet-point lists, which caused the list of exported symbols on the documentation page to not render correctly. This PR adds the needed newlines so that the list renders correctly. This furthermore removes the mention of exporting symbols from std, as this is not actually necessary to access these specialisations (and was removed in a previous PR, #5164).

[nlohmann]

Looks good to me.

[nlohmann]

Thanks!

[mikomikotaishi]

Please be aware that the module is experimental and a full test is outstanding, and the exported symbols are subject to change.

By the way, what else would need to be done before this disclaimer could be removed? What would a full test need to consist of for the module to be no longer experimental? (I'm not in a rush for anything, but I would be interested in providing additional improvements so that it can be stabilised.)

Additionally, is there a reason using json = nlohmann::json; is used throughout the documentation instead of using nlohmann::json; when the latter is more concise and these two do the same thing?

[nlohmann]

By the way, what else would need to be done before this disclaimer could be removed? What would a full test need to consist of for the module to be no longer experimental? (I'm not in a rush for anything, but I would be interested in providing additional improvements so that it can be stabilised.)

I think the best we could do is to provide some mechanism to execute the test suite against the module. Maybe this is possible with some preprocessor magic.

Then we would see if all features actually work at least for some compilers.

Happy to see PRs!

Additionally, is there a reason using json = nlohmann::json; is used throughout the documentation instead of using nlohmann::json; when the latter is more concise and these two do the same thing?

We have some examples where we use using json = nlohmann::ordered_json and then use the same code later on.

[mikomikotaishi]

I think the best we could do is to provide some mechanism to execute the test suite against the module. Maybe this is possible with some preprocessor magic.

Many of the tests I see (the CMake building tests in particular) simply check whether a file compiles after including <nlohmann/json.hpp> and constructing a nlohmann::json. The current modules test does the same thing (and that was how it looked when I first found it); would you like if I made the test a bit more comprehensive to test additional features that the library offers?

I'm not too sure what could be done with preprocessor manipulation, or how much more extensive this would be, but at the very least expanding the current test would provide some greater confidence that things work.

We have some examples where we use using json = nlohmann::ordered_json and then use the same code later on.

Ah, I see, thanks.

Though, wouldn't it be clearer to just write using nlohmann::ordered_json; in those places? Then it would be clear in all places when basic_json or ordered_json is being used, considering json is already a library-defined alias for a template specialisation of basic_json.

[nlohmann]

Maybe the next step should not necessarily be extending the scope of the tests, but rather the scope of the compilers. It would be good to extend https://json.nlohmann.me/community/quality_assurance/ with a list of compilers for which we know the module work.