Add json::partial::copy_and_look_ahead()

[vinipsmaker]

So... I'm so confident this function fills a gap that I went ahead and implemented it before we had the chance to exchange any message about the idea.

Updates #26

[vinipsmaker]

As an example of a protocol that requires to look ahead before we decide the C++ type to be deserialized to, check the BitMEX API: https://www.bitmex.com/app/wsAPI

Before we interpret any other members from the root object, we must check the "op" attribute.

TBH this example is actually not very good because better alternative serializations exist for this specific protocol. However that's a common pattern (an "id"/"type"/"MsgType" field to describe the type instance) and the example is just enough to illustrate this pattern. I'm just pasting literally the first WS API that popped up in my head. I'm not gonna really try to find a second/better example.

[breese]

As we are going the copy the reader anyways, we might as well pass it by value and drop "copy_and_" from the name. This also enables the user to do a "destructive look-ahead" by moving the reader when calling this function.

[vinipsmaker]

As we are going the copy the reader anyways, we might as well pass it by value

Done: 76c9464

This also enables the user to do a "destructive look-ahead" by moving the reader when calling this function.

Indeed. It's a good suggestion.

and drop "copy_and_" from the name.

I'm not sure about this one. So far every partial::* algorithm modified its input argument. It'd be good to have a name hint that something funny is going on. Do you have another suggestion for a name hint? I couldn't think of a better hint.

Conceptually we're still copying. It just happens that we might construct our copy by move. So this excuse can be used.

[breese]

You have a good point that we need to clearly separate between algorithms that modifies the reader and those that do not.

We could let the immutable algorithms take a view instead of a reader. The algorithm may decide to create a reader, but that becomes an implementation detail. Something like this:

template <typename View>
bool contains(View view);

template <typename View>
View find_value(View view, View key);

[vinipsmaker]

We could let the immutable algorithms take a view instead of a reader. The algorithm may decide to create a reader, but that becomes an implementation detail.

That still doesn't tickle right to me. The type becomes invisible when we're calling a function.

foobar(x);

So the type isn't a real hint to help readability.

However this discussion reminds me of std::ref() vs std::cref(). We're already using the namespace name to hint expectations, so maybe we could create a new namespace for algorithms such as look_ahead(). Maybe cpartial (not the best name, but maybe we can think of a better one soon)?