Closed semtexzv closed 9 months ago
This sounds like it would be a nice thing to have, but unfortunately I don't think we will be able to prioritize this any time soon. Text format changes are not easy to do since they have to be implemented in all languages for consistency.
We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.
This issue is labeled inactive
because the last activity was over 90 days ago.
We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please reopen it.
This issue was closed and archived because there has been no new activity in the 14 days since the inactive
label was added.
What language does this apply to? text_format
Describe the problem you are trying to solve. Currently, the text_format s a nice debugging tool, However, there are a few drawbacks, when trying to use it as a proper developer-facing interface. One of the issues is maps. We currently don't have a native syntax for specifying maps, apart from emulating them with messages.
Describe the solution you'd like Add following lines to text_format spec and implement the changes in text_format parser and generator.
Section Fields:
This would allow us to write a following syntax:
This format is already used by
protoc --decode_raw
.Drawbacks Since we're adding new variants to the
Field
syntactic elements, All parsers would have to have one more branch to reject this element if not applicableDescribe alternatives you've considered Changing the spec in following way
Would result in a much simpler grammar, but in this grammar, parser for each message would have to deal with field keys that are literals, and fail if it did not accept the map syntax.
Additional context I'm implementing a protobuf implementation that contains this feature, and since this has been a very useful feature so far, I want to standardize it.