Description
Terraform CLI and Framework Versions
$ terraform version
Terraform v1.3.6
on darwin_amd64
Your version of Terraform is out of date! The latest version
is 1.4.2. You can update by downloading from https://www.terraform.io/downloads.html
$ go list -m github.com/hashicorp/terraform-plugin-framework
github.com/hashicorp/terraform-plugin-framework v1.1.1
Use Cases or Problem Statement
In #80, the metavalidator
package was replaced with concrete implementations for most of the data types. Unfortunately, the boolvalidator
, datasourcevalidator
, providervalidator
, and resourcevalidator
packages didn't get All
, Any
, and friends like the rest of the *validator
packages.
The lack of feature parity in the these package makes it very hard to express logic on boolean attributes in the same way you can on other data types. You either have to roll your own implementation (which is the hard part), or not validate. Both choices are unideal.
Proposal
In order of preference:
-
Add back the
metavalidator
package. However, I think this ship has sailed. So it's fine if this isn't the selected option.My opinion as a provider author is that having to use a different function in a different package for the sake of type safety is more a bug than a feature. It feels like between one of generics and interfaces, there's a solution that would let provider authors have the ease of use to create validations with the same function while also giving the framework the type safety it requires.
-
Add the
All
,Any
, and friends versions to theboolvalidator
,datasourcevalidator
,providervalidator
, andresourcevalidator
packages.I would hope that any validation could be combined with
All
,Any
, and friends. -
Add the
All
,Any
, and friends versions to theboolvalidator
package.I could imagine there might be strong opinions about whether the
datasourcevalidator
,providervalidator
, andresourcevalidator
packages needAll
,Any
and friends. I would rather drop my implementation ofAnyWithAllWarnings
for booleans by at least having theboolvalidator
package implement this behavior, than get bogged down in that opinion. It makes sense to me that anything should be able to combine validators in these ways, but I also am not maintaining this framework so my opinion is only worth so much.If there's opinions about the other three, then just punt and at least have feature parity for the boolean stuff.
Additional Information
No response
Code of Conduct
- I agree to follow this project's Code of Conduct