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
proposal: text/template: support "-" in value maps without "index" #23710
Comments
I think that's why |
Yeah the use of |
Adding this feature could be a sliplery slope. For example, if we ever wanted arithmetic expressions in the template language, it would conflict with hyphens in selectors. I also assume that this proposal is about allowing hyphens/dashes in all names in the template language, not just maps and selectors. |
There is the additional problem that if I think that a better rule would be to validate the identifiers and whenever one such identifier is encountered, inform the user that the correct way to represent the fields is using |
Arithmetic expressions could still be supported, it could simply be written that within a value map structure that's not processed. I'm not looking to add support for |
@grillz what do you mean by "within a value map structure"? The language is parsed statically, so the template parser has no idea if it's going to deal with maps, structs, or whatever other type. All it knows is what a "selector expression" is, like You can come up with rules here, such as "depends on the spacing", but my point is that it complicates the template language. There must be a very good reason to do that, and I honestly don't see it. It would be much easier for helm to work around the issue, either by discouraging the use of dashes, or by rewriting the template pipelines to use the |
don't the templated vals always start with |
a templating language should strive to meet its use cases when it can, unless there is sufficient reason not to. The burden of proof is really on your end as to why this is a bad idea, haven't heard a great answer to that yet. |
@grillz A language, programming or templating, should strive to provide the functionality needed by the users to provide value. The language shouldn't over-complicate itself with sugar or additional features, as that's more code to maintain and limitations to be aware of. This is especially true when there are other means to an end for accomplishing what you want. As someone requesting a feature change to a language, the burden of proof is on you to explain why the current functionality doesn't meet your needs (from a technical perspective). Why should individuals allocate time to implement and maintain this change? Are the risks worth it, especially knowing that the I think more specifically, why is the Answering these questions in a clear way would be helpful in making a determination on the value of adding Edit: If the change seems simple enough, how do you feel about making the change to the Go standard library to support it? |
I think the technical challenges are pretty well documented with the helm case. The use case of taking yaml or json as an input to a template is widely present in our org, and I imagine that to be the case elsewhere. I think the use case of subtraction is easily handled by that fact that value mapping always begins with As far as the use of |
This is how PHP was born. |
@cznic please argue the merits, pretty sure good languages are built on good logical decisions 🙂 |
Sorry, but no - you are proposing a major change to the templating language, so it is the proposal that has to describe with detail its design and why its advantages are greater than its disadvantages. The proposal should be much more detailed than "dashes should work as map keys" and "seems fairly simple". It may seem simple to you, but I still find this proposed change underdeveloped and bringing more complexity than improvement to the language. You have described Helm's problem, but not so much why this is a sensible change to the language or how it would work. I'm repurposing this issue as a proposal, as this is clearly not turning out to be a simple topic. I'll leave it up to the proposal review team to have a look, but I presume that they too will want the proposal to be made clearer if it is to move forward. |
@mvdan thank you for repurposing this into a proposal. As I've stated before, I opened this as an issue because I'm not clear why this wouldn't be the case. I was hoping for an "ah-ha" moment as to the logic behind it, but am still not clear on what that is. I'm also unclear on what complexity this brings to the language. I'll try and restate the benefits: "-" is a very common separator in keys of both JSON and YAML documents, and JSON and YAML documents are frequently used as inputs to templates. The values in these JSON and YAML documents are commonly inputs from other domains. Rather than need to translate any input that uses the common "-" separator into camelcase, it would be very beneficial to support that as an allowed character. These are real problems being worked around today causing frustration with the product. From my brief survey of other templating languages, they do not suffer from this limitation. The change of allowing this character from what I can tell would be entirely backwards compatible. Going forward you would simply have a lot more happy customers 🙂 |
Sorry, but the solutions are to use index or rename the key. We aren't going to expand the identifier set beyond what's there now. It's really meant for struct fields. For non-alphanumeric (non-Go identifier) keys, please use index. |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?1.9
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?darwin amd64
What did you do?
tried to use "-" in a template.
https://play.golang.org/p/VQzgZ0v2iNo
What did you expect to see?
I expect to be able to use "-" in keys because that is a widely used separator in keys
What did you see instead?
an error for using that char
The text was updated successfully, but these errors were encountered: