mirror of
https://github.com/logos-co/logos-cpp-sdk.git
synced 2026-08-31 17:51:07 +00:00
Dario Gabriel LipicarandClaude Opus 5
24a7e9a376
`{tstr: T}` has two C++ spellings — std::map<std::string, T> and
std::unordered_map<std::string, T> — and logos_codec.h specializes Codec for
both, because they are the same wire shape. The generated dispatch named one:
lidlImpl().echoIntMap(logos::fromJson<std::map<std::string, int64_t>>(...))
fromJson returns a std::map, and a std::map does not convert to an
unordered_map parameter. So the container the author picked decided whether
generated code they never wrote compiles — with the diagnostic pointing at
that generated line, not at their declaration.
logos::JsonArg (logos-protocol, already on master) exists for exactly this:
it instantiates its conversion operator with the parameter's own type, so the
author's declaration drives the decode. The return side is the same problem
mirrored, and `logos::toJson(result)` deduces instead of asserting.
Restricted to Map because every other LIDL type has one C++ spelling here,
and because JsonArg documents one target it cannot serve — std::optional<X>,
whose converting constructor out-ranks the proxy's conversion operator. The
Optional branch returns before reaching this code.
For a std::map author nothing changes: JsonArg instantiates the same
Codec<std::map<...>>::from at the same path, and toJson deduces the same T.
Compile-checked against both spellings, including a bad element still failing
with `expected string at arg0.k, got number`. Across the whole workspace the
emitted delta is 5 methods, all in test_fullapi_ext.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>