You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
re: the guarantees of Schema, I'm actually not sure what the answer should be for this.
In my opinion, it MUST match "what is on the wire", so [[T; R]; C] OR [T; R * C] would be "acceptable", but &[T] would NOT be. But I'm not sure if [[T; R]; C] is "more right" (it matches the type, or at least the interface to the type), or if [T; R * C] is "more right" (it matches what the serializer/deserializer does, and the internal representation of the type in memory).
In my opinion, we can limit the scope to "within Postcard's data model", which is why I think either of the two "good" cases are acceptable.
Really, a driving cause right now is that "postcard-dyn must work", but I haven't formed opinions on the further details.
re: the guarantees of
Schema
, I'm actually not sure what the answer should be for this.In my opinion, it MUST match "what is on the wire", so
[[T; R]; C]
OR[T; R * C]
would be "acceptable", but&[T]
would NOT be. But I'm not sure if[[T; R]; C]
is "more right" (it matches the type, or at least the interface to the type), or if[T; R * C]
is "more right" (it matches what the serializer/deserializer does, and the internal representation of the type in memory).In my opinion, we can limit the scope to "within Postcard's data model", which is why I think either of the two "good" cases are acceptable.
Really, a driving cause right now is that "postcard-dyn must work", but I haven't formed opinions on the further details.
Originally posted by @jamesmunns in #181 (comment)
The text was updated successfully, but these errors were encountered: