Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's make this a
*string
to match the Rust typeOption<String>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Label is also optional.
*string
is kind of ugly in Go, so I avoid it. Go standard is to treat""
asnil
. Unless an empty string and nil have different actions (eg. a patch for a profile may use this, so*description == ""
clears the description whiledescription == nil
leaves the description unchanged)We try to stick with the most idiomatic structs in each language. And there is no valid
""
for Admin (it must be a long bech32 string)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The difference for
Label
is that we decided to make it a simple String in Rust as well.I think using plain string works in this particular case, but only we throw away the empty/nil differentiation and because we only use this from Rust -> Go.
It would be nice if we could establish a type pattern that is consistent over all places. With
omitempty
we sendundefined
from Go to Rust where string ornull
is expected. This probably fails when decoding. Also the Go side should error for unexpected JSON values (as this is a JSON interface):null
and bech32 is validThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I have tested this quite a bit last year.
Option<T>
happy convertsnull
and a missing field toNone
.I had issues when Go converted an empty array to
null
and then we tried to parse intoVec<T>
. In that case I overrode GO serialization to produce[]
for empty arrays and keep the Rust type sane.I would like @alpe feedback here, as this is really about keeping canonical Go types. In generally if there is no strong reason to differentiate between "zero-values" and "null", you treat them the same in Go. There is no simple way to differentiate
null
fromundefined
(missing field), even if you use*string
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to second Ethan in this discussion. The
*string
types are very uncommon in Go and only whennil
and empty string are treated differently.omitempty
describes it well as optional field (for any Go developer).For this field we use the
string
type already in other places. For example: https://github.com/CosmWasm/wasmd/blob/master/proto/cosmwasm/wasm/v1beta1/tx.proto#L55