Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is within scope? #192

Closed
whackashoe opened this issue Jan 24, 2016 · 2 comments
Closed

What is within scope? #192

whackashoe opened this issue Jan 24, 2016 · 2 comments

Comments

@whackashoe
Copy link
Contributor

General question with a few examples:

  • json schema
  • alternative encodings such as bson or json5 (ability to swap encoder/decoder)
  • using multi-precision numbers

But on a grander level - what is the scope of nlohmann/json ? Is it to only support base json? Is it to support base json but make it easy to use weird crap? Or hard to use the above (at the benefit of keeping code easier to work with) without maintaining fork? If answer for these is fork may I suggest making a json organization so that forks could be all in one place- could be a potentially nicer namespace than the seemingly random nlohmann namespace 👯

@nlohmann
Copy link
Owner

Hi @whackashoe, thanks for the question.

So far, the goal of the project is to implement RFC 7159 in a way that it feels like a first-class datatype in modern C++.

From my point of view:

  • BSON is currently out of scope, because there is still a lot to learn from completely implementing JSON while preserving a simple syntax and STL-like interfaces.
  • JSON5 is out of scope, because it is an extension which has not received enough traction to justify the effort of adjusting the library.
  • Multi-precision numbers would be an interesting aspect to include, because it would allow to use the code in further scenarios.

In any case, if I had the choice between simplicity to use the code in "vanilla" JSON scenarios (as a user who just wants to include a single header and have JSON support) and adding a feature, I'd always choose the former.

About the namespace: I have no idea what else to name it. The only name I would really prefer would be "std", but we're not there yet ;-)

However, would like to discuss this. Maybe I am missing a point.

@nlohmann nlohmann added the state: please discuss please discuss the issue or vote for your favorite option label Jan 24, 2016
@nlohmann
Copy link
Owner

related: #150

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants