Separate container concepts #319

[justend29]

• commit 4dd573f contains exclusively autoformatting, and diffs can be made against that to see exclusively code changes
• map_t has been split into readable_map_t and writable_map_t, as discussed in Separate concepts for reading and writing containers #319
• the to_json<writable_map_t>::op() function needed to be slightly changed to depend less on the member functions of standard associative containers and instead operate a bit more generically. This allowed operating on input ranges
  • there was also what I think was a slight bug that was fixed in this rewrite
• in the same line, T::value_type was replaced with range_value_t throughout the code

Note:
std::pairs are currently serialized as arrays of the form [first, second]. Existing code that serializes an array of pairs would expect [[first1,second1], [first2,second2],... ]
This PR changes that behaviour, as that array will now be considered an input range of pairs (map-like), and print them as objects. That is technically a breaking change.

It kind of seems more appropriate to serialize pairs as objects w/ a single entry of the form {"first": second}. We could lean into the breaking change and serialize single pairs as objects. May just be a preference, though.

[justend29]

@stephenberry I cannot immediately see why MSVC fails to compile from the error logs in CI. I'll run a VM to compile this locally with MSVC to hopefully understand why it's mad. Maybe this weekend - we'll see what time permits.

[stephenberry]

As a heads up, I'm working on fixes to MSVC on another pull request which should fix your builds here.

[stephenberry]

@justend29 MSVC 2022 now builds, and most of the 2019 errors have been fixed, but it seems to have problems with the ranges, and I think it's wrong. I'm really tempted to drop MSVC 2019 support, because there are so many hacks needed to get it to work and I'm starting to need to disable features for that compiler.

[justend29]

@stephenberry Thanks for those MSVC fixes. Is my understanding correct, that this PR will wait until either MSVC2019 support is dropped or more hacks and introduced to support it w/ the ranges introduced here?

Did you have thoughts about the changes themself - particularly, the "breaking" change and the handling of individual pairs?

[stephenberry]

@justend29 I intend to drop MSVC 2019 and merge this request. So, no need to fix the bugs.

I agree with you and I think std::pair should be interpreted as a key:value pair. A std::array<T, 2> or std::tuple of size 2 can be treated as a JSON array.

Can you update std::pair handling and add some unit tests for std::pair?

Changing:

auto num_view = std::views::iota(-2, 3) | std::views::transform([](const auto i) { return std::pair(i, i * i); });

to

auto num_view = std::views::iota(-2, 3) | std::views::transform([](const auto i) { return std::tuple(i, i * i); });

writes out the numbers as an array of arrays, which I think is great if the user wants that syntax. So I like how simple it is to get object syntax by just changing the code to use std::pair. Great work!

[justend29]

I'll absolutely update the handling of pairs with tests!
I'm glad you're happy with it :)

[justend29]

@stephenberry I've added reading & writing specializations for pairs, separating them from tuples.

I'll note that specializations for reading & writing binary were necessary in addition to the specializations for json. I am not familiar with glaze's binary mechanics, so I just used my judgment based on reading the code. I think you should review it thoroughly.

[stephenberry]

Thanks for all your additions. I'm going to merge. I looked over the binary handling and it looks good.

[justend29]

@stephenberry is that a typo at the end of the README?

[stephenberry]

@justend29, haha, thanks for pointing that out. Fixed.