52d01bb915
These changes remove the `Ptr` variants of input/ouptut types for
resources. A `TPtr` input or output is normally generated for `T` if `T`
is present in an `optional(input(T))` or `optional(output(T))` and if
the Go representation for `T` is not nilable. The generation of `Ptr`
variants for resource types breaks the latter rule: the canonical
representation of a resource type named `Foo` is a pointer to a struct
type named `Foo` (i.e. `*Foo`). `Foo` itself is not a resource, as it
does not implement the Go `Resource` interface. Because this
representation already accommodates `nil` to indicate the lack of a
value, we need not generate `FooPtr{Input,Output}` types.
Besides being unnecessary, the implementation of `Ptr` types for
resources was incorrect. Rather than using `**Foo` as their element
type, these types use `*Foo`--identical to the element type used for
the normal input/output types. Furthermore, the generated code for
at least `FooOutput.ToFooPtrOutputWithContext` and `FooPtrOutput.Elem`
was incorrect, making these types virtually unusable in practice.
Finally, these `Ptr` types should never appear on input/output
properties in practice, as the logic we use to generate input and output
type references never generates them for `optional({input,output}(T)).
Instead, it generates references to the standard input/output types.
Though this is _technically_ a breaking change--it changes the set of
exported types for any package that defines resources--I believe that in
practice it will be invisible to users for the reasons stated above.
These types are not usable, and were never referenced.
This is preparatory work for #7943.
376 B
376 B
Improvements
- [codegen/go] - Remove
ResourcePtrtypes from generated SDKs. Besides being unnecessary--Resourcetypes already accommodatenilto indicate the lack of a value--the implementation ofPtrtypes for resources was incorrect, making these types virtually unusable in practice. #8449