How to handle std::pair, std::vector<std::pair..., and std::ranges of std::pair?

[stephenberry]

Currently Glaze treats std::vector<std::pair... and similar ranges of pairs as objects. This enables clean and fast ranges code like the following:

auto remap_user_port = [](const auto port) { return port + 1024; };
auto user_ports = {std::pair("tcp", std::views::iota(80, 83) | std::views::transform(remap_user_port)),
                            std::pair("udp", std::views::iota(21, 25) | std::views::transform(remap_user_port))};
expect(glz::write_json(user_ports) == glz::sv{R"({"tcp":[1104,1105,1106],"udp":[1045,1046,1047,1048]})"});

A problem is that this breaks the normal behavior of a std::vector, which would generate an array. And std::pair, which would be a single key/value element. This concatenates the pairs into a single object, which is a great feature, but breaks expected behavior for someone used to using Glaze more generally.

Glaze provides the concatenate compile time option, which when turned off, just writes the output as an array of single element key/value pairs. This is default on, which makes the default behavior more esoteric.

Another issue is that std::vector<std::pair does not currently roundtrip in concatenated object form. Often a user who is using ranges in this way wouldn't read into the ranges structure, but rather a map type. However, a std::vector<std::pair... has very concrete memory allocated that should roundtrip. The issue is that this type has no guarantee of being sorted, and so Glaze would have to perform a linear search for every key in the array if it were to behave like other object types in Glaze. Yet, in this use case, most users would probably want the input to simply be overwritten rather than replace values, which would eliminate the need for any searching or hashing. But, this breaks the convention of how objects are read in Glaze.

This lacking in roundtrip ability has caused multiple issues that are still active: #1000, #1265, and #1416

[stephenberry]

The concept for a map fits well into the idea that the type is a range (has a begin and end) and its value type is a pair. Both a std::map and a std::vector<std::pair fit into this definition. So, it isn't strange to serialize the std::vector<std::pair as a map.

The issue is deserialization, because we don't want to do a linear search. I feel that the std::vector<std::pair should just be completely overwritten if it is not map_subscriptable, meaning that the value cannot be extracted from a keyed lookup on the access operator. This would make the type round-trippable.

Would it create too much confusion for a std::vector<std::pair to be cleared and overwritten on a read? My fear is that for custom map types, if they aren't map_subscriptable then rather than a compile error, the underlying behavior changes. But, this would be a rare case.

[stephenberry]

A solution has been merged in #1418