-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for named strings as inlined map keys #54
base: master
Are you sure you want to change the base?
Add support for named strings as inlined map keys #54
Conversation
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 think this change is generally okay, but we do need to restrict it a bit further.
@@ -145,7 +145,7 @@ func makeStructFields(root reflect.Type) (structFields, *SemanticError) { | |||
switch { | |||
case tf == jsontextValueType: | |||
f.fncs = nil // specially handled in arshal_inlined.go | |||
case tf.Kind() == reflect.Map && tf.Key() == stringType: | |||
case tf.Kind() == reflect.Map && tf.Key().Kind() == reflect.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.
What happens if tf.Key()
implements encoding.TextMarshaler
(or encoding.TextAppender
), MarshalerV1
or MarshalerV2
?
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.
At mininum, we should forbit any named string
type that can marshal itself, but that does open up the door to problematic situations where someone adds a marshaler to named string type after the fact, causing this to no longer be marshalable. However, I think that situation is okay as it's generally not safe to add a marshaler after the fact.
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.
What happens if tf.Key() implements encoding.TextMarshaler, MarshalerV1 or MarshalerV2?
Any custom marshalers/unmarshalers were ignored for inlined map keys.
I agree that it makes more sense to forbid key types that implement JSON marshal or unmarshal methods. I've added that restriction and included a couple of tests.
that does open up the door to problematic situations where someone adds a marshaler to named string type after the fact, causing this to no longer be marshalable. However, I think that situation is okay as it's generally not safe to add a marshaler after the fact.
FWIW, this is currently the case for inlined structs as well. So, the proposed change remains consistent with the existing implementation.
There isn't a good reason why map[~string]T fields cannot be inlined, unlike map[string]T. This allows map[K]T fields, where K is a ~string type, to be inlined.
f9a9eeb
to
44d27d4
Compare
PTAL? |
There isn't a good reason why
map[~string]T
fields cannot be inlined, unlikemap[string]T
. This allowsmap[K]T
fields, whereK
is a~string
type, to be inlined.