Boost :

plashkari628_at_[hidden]

----
RESULT
----
Boost.JSON is ACCEPTED into the Boost. Now the process to transition
repository to boost can start and get this library published in next
release according to the guidelines.
There was some heat around the discussion, I would like to clarify that
this is not a completely democratic decision. Though there are more accept
votes but I was a bit leaned toward the arguments made in the favour of
reject as those arguments were analysed thoroughly and on point and I
agreed with them. On the other hand, considering the targeted audience and
the goal of the library those arguments are weighed less in my opinion.
"Can't reject an Apple because it is not an Orange". In general, the
library looks great to me and I am sure it will attract new users too
because it has good documentation, friendly APIs and design and good
performance too.
----
REVIEWS
----
There was a good amount of discussion and definitely more reviews than I
expected including a few first-time reviewers.
Summary:
Accept: 14
Reject: 3
Conditional accept: 1
Some positive reviews:
 It is very good, and meets the highest Boost standards. I mean both the
> tutorial and reference sections. While doing this review I had to look at
> the documentation of the competing libraries, and they are really bad. This
> is why I can appreciate the big effort you put in making these docs. There
> is a section "Comparison" that compares Boost.JSON to other JSON
>  libraries.
> I personally think it should also mention the documentation.
The design takes some time to get used to, but it fits well to the
> problem being tackled (a JSON-DOM library).
> Switching my codebases using RapidJSON to this library made the code
> more readable and it will also allow me to get rid of a significant
> amount of boilerplate.
The fact that this value type has been highly optimized is the great
> strength of this library.
Design is very good. The parser interfaces and object building interfaces
> meet my needs. I especially want to call out the pmr support and it's
> support for either sharing or transferring ownership of resources.
Some critical reviews:
Binary size matters a lot, since onboard Flash is very limited. I am
> using a "big" MCU, and that means my whole binary must be under ~512 KB.
> Right now Boost JSON is not great. In doing a simple serialization and
> parse, the library itself adds ~58 KB to my .text section. This is OK for
> now, but surprisingly big. I know the team is aware of this and has some
> ideas to reduce the binary size. I will likely need those fixes to actually
> port my app to Boost JSON.
It would be better for the library to just template on allocator just like
> the vector class in the C++ standard
...and many more positive and critical reviews...
A Thing I was explicitly asked to note:
> The memory management model is extremely simple. I wonder if storage_ptr
> could be moved somewhere else long term so other libraries can use it.
I think that's it. I would like to thank everyone who was involved in the
review process every review was important and gives new insight and helps
to make boost better.
Best of luck to the authors and the maintainers of the library.
-- 
Thank you,
Pranam Lashkari, https://lpranam.github.io/