You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// Variadic parameters are represented as a TupleType where each element type of the tuple matches the variadic parameter type.
136
+
// Variadic parameters are represented as a framework Tuple where each element type of the tuple matches the variadic parameter type.
137
+
//
138
+
// MAINTAINER NOTE:
139
+
// Variadic parameters are represented as individual arguments in the CallFunction RPC and Terraform core applies the variadic parameter
140
+
// type constraint to each argument individually. For developer convenience, the framework logic below, groups the variadic arguments into a
141
+
// framework Tuple where each element type of the tuple matches the variadic parameter type.
142
+
//
143
+
// Previously, this logic utilized a framework List with an element type that matched the variadic parameter type. Using a List presented an issue with dynamic
144
+
// variadic parameters, as each argument was allowed to be any type "individually", rather than having a single type constraint applied to all dynamic elements,
145
+
// like a cty.List in Terraform. This eventually results in an error attempting to create a tftypes.List with multiple element types (when unwrapping from a framework
146
+
// dynamic to a tftypes concrete value).
147
+
//
148
+
// While a framework List type can handle multiple dynamic values of different types (due to it's wrapping of dynamic values), `terraform-plugin-go` and `tftypes.List` cannot.
149
+
// Currently, the logic for retrieving argument data is dependent on the tftypes package to utilize the framework reflection logic, requiring us to apply the a type constraint
150
+
// that is valid in Terraform core and `terraform-plugin-go`, which we are doing here with a Tuple.
137
151
//
138
-
// This is intentional and meant to match how variadic arguments are handled by Terraform core,
139
-
// where the variadic parameter type constraint is applied to each argument individually.
// Variadic parameters are represented as a TupleType where each element type of the tuple matches the variadic parameter type.
136
+
// Variadic parameters are represented as a framework Tuple where each element type of the tuple matches the variadic parameter type.
137
+
//
138
+
// MAINTAINER NOTE:
139
+
// Variadic parameters are represented as individual arguments in the CallFunction RPC and Terraform core applies the variadic parameter
140
+
// type constraint to each argument individually. For developer convenience, the framework logic below, groups the variadic arguments into a
141
+
// framework Tuple where each element type of the tuple matches the variadic parameter type.
142
+
//
143
+
// Previously, this logic utilized a framework List with an element type that matched the variadic parameter type. Using a List presented an issue with dynamic
144
+
// variadic parameters, as each argument was allowed to be any type "individually", rather than having a single type constraint applied to all dynamic elements,
145
+
// like a cty.List in Terraform. This eventually results in an error attempting to create a tftypes.List with multiple element types (when unwrapping from a framework
146
+
// dynamic to a tftypes concrete value).
147
+
//
148
+
// While a framework List type can handle multiple dynamic values of different types (due to it's wrapping of dynamic values), `terraform-plugin-go` and `tftypes.List` cannot.
149
+
// Currently, the logic for retrieving argument data is dependent on the tftypes package to utilize the framework reflection logic, requiring us to apply the a type constraint
150
+
// that is valid in Terraform core and `terraform-plugin-go`, which we are doing here with a Tuple.
137
151
//
138
-
// This is intentional and meant to match how variadic arguments are handled by Terraform core,
139
-
// where the variadic parameter type constraint is applied to each argument individually.
0 commit comments