Documentation: specify if ParameterWith<type>Validators is intended for external usage

[mschuchard]

At the moment the documentation contains multiple types for the function package with names such as ParameterWith<type>Validators. These types are also (of course) public. These types contain member fields for Parameter type inputs and slices of <type>ParameterValidator. At the moment these types all appear to mostly facilitate "get" return functionality for the module, and not really support inputs. However, the definition signatures would appear to be interesting if they could be externally consumed.

Could the Go package documentation for the ParameterWith<type>Validators please be updated to specify if these are for module internal usage, or whether they are external facing?

[mschuchard]

I understand everyone is probably super busy, but is it possible for even a super quick yes/no on whether these are intended for external usage (or even could be potentially leveraged as such now or in the future), or are purely internal to the framework module?

[austinvalle]

Hey @mschuchard 👋🏻 , apologies for the delay. I think it's fair to say the documentation should be updated to be more explicit about the usage of these interfaces. I'll tag this issue to reflect that.

The ParameterWith<type>Validators are external and can be used, however they're only really useful if you're implementing a custom Parameter implementation that you'd want to support parameter validators.

Currently, Framework already implements all of the parameter types you'd likely want (like StringParameter), so I don't see a ton of value in consuming them at the moment (unless you wanted to build a custom parameter instead of a custom type, for example, like an IPv6Parameter with some built-in validation).

[mschuchard]

Ok so they validate the Parameter and not the input Parameter Value. I misinterpreted due to their similar name with the validators used with the resource and data schema.
Thank you for the clarification, and even a one sentence update to the godoc explaining usage would indeed be super great.

Currently, Framework already implements all of the parameter types you'd likely want

I completely agree as the Dynamic type basically enables generics, and I have already successfully implemented it for what would be a Tuple in HCL2 (which the plugin framework documentation even mentions as a possible use case).