Replies: 1 comment 2 replies
-
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. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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:
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).std::unique_ptr<>, std::shared_ptr<>, std::wstring, std::vector<char>
. The missing specializations forstd::wstring, std::vector<char>
makes serialization go through field_printer, which doesn't add single quotes.std::nullptr_t, std::optional<>
are wrong: they don't considercontext.replace_bindable_with_question
, hence always replace a literal with a question mark.field_printer<pointer_binding<P, T, D>>
in the wrong place; it rather should bestatement_serializator<pointer_binding<P, T, D>>
.So, the key question:
statement_serializator<T, is_bindable_v<T>>
, utilizingfield_printer<T>
for it?statement_serializator<T, is_bindable_v<T>>
only a fallback and utilizingfield_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.
Beta Was this translation helpful? Give feedback.
All reactions