-
Notifications
You must be signed in to change notification settings - Fork 13
Description
Terraform CLI and Framework Versions
N/A
Use Cases or Problem Statement
Following #238, the remaining validators that don't support parameter validation (used in provider-defined functions) that are able to are:
Any
+AnyWithAllWarnings
for all validator packagesAll
for all validator packagesmapvalidators.KeysAre
Value{TYPE}sAre
for all collection validator packages, likelistvalidator.ValueStringsAre
Proposal
These "logical" validators all accept in the attribute-based validator interface, like validator.String
, which differ from the parameter-based validator interface, like function.StringParameterValidator
. The differences are small however (notably error handling and data available), and are not relevant for the mentioned validators.
These validators all accept the attribute-based validator as input and we'd prefer to not introduce breaking changes by modifying/adding new inputs.
Two possible options I see (there could be others!):
- In these validators, add type assertion logic to split/distinguish which validations should run on parameters vs. attributes and handle everything internally.
- Introduce new
Any
/All
/etc. variants that only work with parameter-based validation and accept that interface as input
Overall I think 1 is more preferable, however that does mean that anyone wanting to use the All
/Any
/etc. validators with function parameters would need to implement the attribute-based interface on any sub validators. This isn't necessarily a problem for the common validators in this Go module, but could be annoying for custom validators.
Additional Information
No response
Code of Conduct
- I agree to follow this project's Code of Conduct