Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

nickkhyl
Copy link

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.

Copy link
Collaborator

@dsnet dsnet left a 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.

\cc @mvdan @johanbrandhorst

@@ -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:
Copy link
Collaborator

@dsnet dsnet Oct 14, 2024

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?

Copy link
Collaborator

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.

Copy link
Author

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.
@nickkhyl nickkhyl force-pushed the nickkhyl/allow-named-string-key-inlining branch from f9a9eeb to 44d27d4 Compare October 15, 2024 00:35
@nickkhyl
Copy link
Author

PTAL?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants