Relationship between field_printer and statement_serializator

[trueqbit]

I ran into confusion in regard to the relationship between statement_serializator and the field_printer while working on #928, amending the pointer-passing-interface, plus trying to unit test the serialization of 'bindable' literals or variables.

The internally documented use of field_printer is for dumping an object using storage_t::dump(Object{}).
However it is also used as a fallback for all 'bindable' literals or variables by statement_serializator.

This is causing some confusion on my side:

• there are specializations of statement_serializator<> for some non-arithmetic types: std::nullptr_t, std::optional<>, const char*, std::string, std::string_view while others are left out and go through the fallback (see next bullet point).
• However there are no specializations for: std::unique_ptr<>, std::shared_ptr<>, std::wstring, std::vector<char>. The missing specializations for std::wstring, std::vector<char> makes serialization go through field_printer, which doesn't add single quotes.
• The specializations for std::nullptr_t, std::optional<> are wrong: they don't consider context.replace_bindable_with_question, hence always replace a literal with a question mark.
• If field_printer is just an implementation detail for statement_serializator, then I put field_printer<pointer_binding<P, T, D>> in the wrong place; it rather should be statement_serializator<pointer_binding<P, T, D>>.

So, the key question:

1. Is it desirable to serialize all 'bindables' through one statement_serializator<T, is_bindable_v<T>>, utilizing field_printer<T> for it?
2. Is serializing 'bindables' through statement_serializator<T, is_bindable_v<T>> only a fallback and utilizing field_printer<T> only an implementation detail?

Whichever way we choose, printing of bindables should probably be fixed in a such way that numbers are always printed/serialized unquoted, strings quoted, and hexified binary data quoted with a 'b' prefix.

[fnc12]

Your confusion is expected cause you entered the legacy part of the lib. What you are saying is right. Let's fix it. One important thing: don't break current tests and examples.

[trueqbit]

Alright, so which of the two points above do you prefer or think are more correct - or what was your original intention?

Also, should storage_t::dump()+field_printer be changed such that it doesn't always quote the printed value but rather relies on the field printer?

I think we need some Slack channel or other contribution tool in order to discuss things.

[fnc12]

storage_t::dump is designed to print all values with quotes just to look like JSON. I don't see any reason of changing it. But if you find any bugs in statement_serializator it needs to be fixed of course.

Please tell me your email for slack invite

[trueqbit]

The takeaway is that we chose option 1: there's a statement serializer that matches all "bindables" [statement_serializer<T, is_bindable_v<T>>], where serialization of each type is then implemented as needed.