function: Switch the representation of variadic arguments to types.Tuple

[austinvalle]

This PR contains a breaking change to provider-defined function handling for variadic parameters, switching the framework type representation from types.List to types.Tuple, where each element is the same element type.

If provider developers are utilizing slice reflection to retrieve variadic argument values, there will be no changes required due to the updates to support tuple reflection, noted below in Reflection Changes:

func (f *ExampleFunction) Run(ctx context.Context, req function.RunRequest, resp *function.RunResponse) {
    var boolArg bool
    var stringVarg []string

    // Despite being a tuple[string,string,etc.] under the hood, reflection will still work here
    resp.Diagnostics.Append(req.Arguments.Get(ctx, &boolArg, &stringVarg)...)
}

Context

Initially, we grouped all variadic arguments for a provider-defined function into a types.List to emulate a similar experience to Go variadic function arguments which are represented by a Go slice. However Terraform core does not handle variadic arguments as a cty.List, but rather a []cty.Value, with the type constraint of the variadic parameter applied to each argument individually.

The difference in this handling is specifically problematic when introducing dynamic type support for variadic function parameters, because Terraform will not attempt to conform all variadic arguments to the same type (like a cty.List would), eventually causing a decoding error in terraform-plugin-go that a provider developer cannot avoid.

While the framework type system doesn't have the same decoding issue as tftypes/terraform-plugin-go, we need to convert values into tftypes to utilize the framework reflection logic 🙂. Switching to types.Tuple will allows both tftypes and the framework type system to be utilized.

Reflection Changes

This PR also contains an implementation of limited reflection support for TupleType (off the interface attr.TypeWithElementTypes). These changes are only intended to support reflection use-cases for tuples where all element types are the same, which will allow provider functions like the following to work properly:

func (f *ExampleFunction) Definition(ctx context.Context, req function.DefinitionRequest, resp *function.DefinitionResponse) {
    resp.Definition = function.Definition{
        // ... other fields ...
        Parameters: []function.Parameter{
            function.BoolParameter{},
        },
        VariadicParameter: function.StringParameter{
			Name: "variadic_param",
        },
    }
}

func (f *ExampleFunction) Run(ctx context.Context, req function.RunRequest, resp *function.RunResponse) {
    var boolArg bool
    var stringVarg []string

    resp.Diagnostics.Append(req.Arguments.Get(ctx, &boolArg, &stringVarg)...)

    // ... other logic ...
}

Notes

• Only the reflect.Into changes are necessary for provider-defined function support, however I implemented the BuildValue equivalent for tuples for completeness 😄

[bflad]

Looks good to me 🚀 This will let us iterate forward.

[bflad]

Does this need an exception for successfully working with []attr.Value that should be able to accept multiple element types?

[austinvalle]

This sparked an offline conversation about "why exactly we need to utilize a Tuple instead of a List".

I have attempted to distill that conversation into a maintainer comment. @bendbennett + @bflad if you could take a look at 6dfc032, let me know if that makes things more/less confusing 😆

EDIT: (I removed the top line since I repeated it in 43aecc9)

[bendbennett]

Thanks for adding the maintainer comment, the expanded context is very useful.

[bendbennett]

LGTM 🚀

[bflad]

Looks good to me 🚀

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.