hashicorp
Support thousand separator for number type values
Terraform Version
Terraform v1.13.4
on darwin_arm64
Use Cases
When writing big numbers it is hard to visually see what number it is. For a concrete example, the terraform-aws-provider supports the cloudwatch_metric_alarm resource which has a field called threshold (see https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cloudwatch_metric_alarm#threshold-1).
You can use this resource to create an alert in AWS Cloudwatch if a specific value does not pass the check. In case of storage, the value has to be written in bytes. Representing a GB will make your write a number such as 1000000000 which is really hard to read. You could work around it by doing 1000 * 1000 * 1000 instead.
The same is true for numbers that represent seconds in resources. Usually its better to do a calculation to make the user aware of that fact.
Attempted Solutions
As mentioned above, instead of writing the number, it can be replaced with a calculation that represents the number e.g.
1000000000 -> 1000 * 1000 * 1000
86400 -> 60 * 60 * 24
Proposal
Before I propose a solution, please be aware of the following:
Neither go nor JSON natively support a way to "pretty-print" numbers in code. Thus, it would be a custom feature to terraform/HCL to recognize such numbers.
Proposal: Allow numbers to be written in a way that separates the value of thousand for better readability of the code. Which separator to be used is up to the implementation.
Suggestions are , (C#, Python), ' or _.
References
No response
Thanks for this feature request! If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions. Thanks again!
That could become quite a mess because there's difference in what the decimal and thousand separators are in other countries than the US.
That could become quite a mess because there's difference in what the decimal and thousand separators are in other countries than the US.
Absolutely agree. Thus, I'd recommend to use something already present in other languages such as Python which has been researched in PEP378.