RFC: [Go] Generics in the Pulumi SDK

[abhinav]

Hey folks!

We've been exploring what it would take to introduce generics to the Pulumi Go SDK. We have a direction that we're reasonably happy with, so we'd like to post it here publicly to gather feedback as we begin implementing it.

Please have a look at the document below and feel free to share your thoughts with us.

Thanks!

---

Simplifying the Pulumi Go SDK with generics

Issue: #9143

• Abstract
• Background
  • Prior work
  • Motivation
• Design
  • Concepts
  • Backwards compatibility
  • Literals
  • Composition
  • Containers
• API Summary
• Off-ramp
  • Phase 1: Generics rollout
  • Phase 2: Provider migration
  • Phase 3: Pulumi v4
• Future work
• FAQ
• Appendix

Abstract

This document proposes an alternative API for the Pulumi Go SDK that leverages type parameterization (generics) to reduce complexity and improve ergonomics of the SDK.

It proposes a way to achieve this API in a backwards-compatible manner with a gradual off-ramp from the current APIs for when we're ready for a major version bump.

Background

The Pulumi Go SDK was designed before Go had support for generics. The SDK offers the best experience it could given the constraints of the language at the time.

The language has since evolved and added support for generic types and functions. This unlocks a host of improvements that we could make to the Go SDK for Pulumi.

Prior work

In a prior Hackathon, @AaronFriel put together a prototype incorporating generics into Pulumi's Go SDK. He demonstrated how a completely new API could replace the Input and Output types. This API is summarized in Appendix: Hackathon Prototype.

Motivation

This section talks about a few problems with the Pulumi Go SDK today that we use as motivation for choices in the new design.

Unsafe Inputs, Outputs, and Apply

This is perhaps the most common complaint about the Pulumi Go SDK. The Input and Output types, and the apply operation all rely heavily on interface{}. This makes them effectively untyped at compile-time, instead relying on type matching at runtime.

For instance, the apply operation is implemented in Go as the following method:

func (*OutputState) ApplyT(interface{}) Output

The contract for ApplyT states that applier must be a function with one of the following signatures:

func(U) T
func(U) (T, error)

Where U must be assignable from the type contained in the underlying Output. If it isn't, the operation will panic.

The caller will usually want to cast the result into a specific output type. If they choose the wrong output type, this operation will panic.

So given a typical usage like the following, there are two spots that can panic: the ApplyT invocation and the IntOutput cast.

intOutput := stringOutput.ApplyT(func(v string) int {
    return len(v)
}).(pulumi.IntOutput)

Excessive code generation

The Go SDK relies heavily on code generation in an attempt to alleviate the pain of untyped operations. It generates type-specific input and output wrapper types for nearly every type it encounters.

In the core Pulumi SDK, this includes all primitive types, their pointers, containers, and containers of containers. For instance, the core SDK has 22 String* types besides type String itself, covering nearly all variations of the following pattern:

String(Ptr|(Array|Map)?(Array|Map))?(Input|Output)?

flowchart LR
    String; Input; Output
    subgraph "Level 1"
      Ptr; Array; Map
    end
    subgraph "Level 2"
        Array2[Array]; Map2[Map]
    end
    String & Ptr & Array & Map & Array2 & Map2 --> Input & Output
    String --> Ptr & Array & Map
    Array & Map --> Array2 & Map2

This pattern of code generation carries over to code generated from schemas, though not to this degree of nesting. Every type gets an input and output type, a pointer variant if the type is referenced as a pointer, and container variants if the type is referenced from a container.

In general, this generates extremely large packages that are ungainly to navigate—both in source form and in their API reference. This can even lead to code generation timeouts.

Redundant container types

Related to the previous issue is the fact that the Go SDK generates container wrapper types at all. These exacerbate the difficulty in navigating the code or documentation for a generated package. As of writing this, 85% of the output types in the Pulumi core SDK, and over half the output types in the AWS S3 package, are container or pointer types.

The following table contains rough counts of output types in different Pulumi packages and the portion of them that are array, map, or pointer types.

Package	Outputs	Arrays	Maps	Pointers
pulumi/v3	79	31	31	6
aws/s3	313	71	26	67
eks	39	9	8	5
azure/storage	206	56	26	25
command/remote	7	2	2	0

Design

Based on the motivations above, the new design has two high-level goals:

• incorporate type-safety into the core concepts: inputs, outputs, and apply
• reduce the amount of generated code—this isn't strictly necessary but it's nice to have

The design also has the following logistical requirements:

• Maintain full backwards-compatibility: Breaking changes are a non-starter in the short term.
• Support gradual migration: The design must not split the ecosystem, where you either use the old APIs or the new APIs, but not both. Users must be able to upgrade their code gradually.
• Plan an off-ramp: There must be a viable plan to delete the old untyped APIs with minimal churn when we're ready for a major version bump.

Concepts

We will put aside the backwards-compatibility requirement temporarily and discuss how the core Pulumi concepts (Input, Output, and Apply) could be made type-safe. Backwards compatibility is discussed below separately.

Output

Output is defined as a generic type that embeds OutputState. This operates like any other custom output type today.

type Output[T any] struct{ *OutputState }

Input

Input is a generic interface that may be used as a type constraint. Similar to how generated input types operate today, an input for a type is any value that can convert itself into an output of that type.

type Input[T any] interface {
    pulumi.Input // this is the current Input interface

    ToOutput(context.Context) Output[T]
}

The interface additionally embeds the existing pulumi.Input interface for backwards compatibility. See Conceptual Compatibility for details.

Note that existing generated FooInput types have both ToFooOutput and ToFooOutputWithContext methods. We're opting for a single method that always expects a context to encourage having a context passed in more often. This API is not intended for use by end users (although they are allowed to), so we don't need to optimize its ergonomics for the zero arguments case.

Output[T] implements this interface:

func (o Output[T]) ElementType() reflect.Type

func (o Output[T]) ToOutput(context.Context) Output[T]

Apply

With the types above, it's possible to implement a type-safe Apply function with the following signature:

func Apply[T Input[I], I, O any](T, func(I) O) Output[O]

Given a value that can become an output, and a function that consumes its result, return an output holding that function's result.

flowchart LR
  subgraph "Input"
    I
  end
  subgraph "Output"
    O
  end
  I --> F["func(I) O"] --> O

We will also include variations of Apply with context and error support.

// context, no error
func ApplyContext[T Input[I], I, O any](
  context.Context, T, func(I) O,
) Output[O]

// error, no context
func ApplyErr[T Input[I], I, O any](
  T, func(I) (O, error),
) Output[O]

// context and error
func ApplyContextErr[T Input[I], I, O any](
  context.Context, T, func(I) (O, error),
) Output[O]

Join

The existing Output.ApplyT method handles Outputs of outputs. We cannot express this cleanly with a type-safe Apply function.

To facilitate this unwrapping, we'll introduce a Join function:

func Join[O any, I Input[Output[O]]](I) Output[O]

flowchart LR
  subgraph "Input"
    subgraph Output1 [Output]
      O1["O"]
    end
  end
  subgraph Output2 [Output]
    O2["O"]
  end
  O1 --> F["Join"] --> O2

Note: O is the first type parameter. See Why are Join's type parameters out of order? for details.

Backwards compatibility

There are two aspects to backwards compatibility for the new design:

• Library compatibility: Code that works today should continue to work. This is the standard definition of backwards compatibility.
• Conceptual compatibility: There must be a way to connect old and new definitions of library concepts, allowing them to co-exist in the same codebase. This is critical to prevent a split ecosystem.

We'll talk about conceptual compatibility first since that further informs the design.

Conceptual compatibility

The Concepts section provided new definitions of Input, Output, and Apply. We need these to be compatible with existing definitions of those same concepts. As a refresher, current definitions (in Pulumi v3) are summarized in Appendix: Concepts in v3.

To avoid ambiguity, this section will refer to current definitions with the namespace pu and the new generic APIs with the namespace pux. We're trying to introduce the following replacements:

Current	Proposed
pu.Input	pux.Input[T]
pu.Output	pux.Output[T]
pu.Output.ApplyT	pux.Apply

For conceptual compatibility, we have the following needs

• Upgrading:
  • use a pu.Output as a pux.Input[T]
  • use a pu.Output as a pux.Output[T]
• Downgrading:
  • use a pux.Output[T] as a specific pu.Input extension
  • use a pux.Output[T] as a specific pu.Output implementation

Upgrading

Upgrading to pux.Input

To support upgrading a pu.Output type into a pux.Input[T], we'll have all generated input and output types implement the ToOutput method to satisfy pux.Input[T]. For example:

func (o StringOutput) ToOutput(context.Context) pux.Output[string]

This is enough to turn all old-style output implementations into valid, strongly-typed pux.Input[T]. More importantly, this makes all these implementations into valid inputs to pux.Apply with signatures and types checked at compile time!

var (
    o pu.StringOutput = // ...
    f func(int) bool  = // ...
)

// Before:
// Compiles fine, but panics at runtime.
o.ApplyT(f)

// Proposed:
// Does not compile.
pux.Apply(o, f)

Being able to upgrade like this makes it nearly free for users to begin using the type-safe APIs.

var (
    s pu.StringOutput  = // ...
    f func(string) int = // ...
)

// Before:
i := s.ApplyT(f).(pu.IntOutput)
// TypeOf(i) => pu.IntOutput

// Proposed:
i := pux.Apply(s, f)
// TypeOf(i) => pux.Output[int]

Upgrading to pux.Output

Being able to upgrade a pu.Output to pux.Input[T] should suffice for most cases, but when a user specifically needs a pux.Output[T], they'll be able to use ConvertTyped or MustConvertTyped:

// ConvertTyped returns an error if T does not match the element type.
func ConvertTyped[T any](pu.Output) (Output[T], error)

// MustConvertTyped panics if T does not match the element type.
func MustConvertTyped[T any](pu.Output) Output[T]

For example:

var s1 pu.Output          = // ...
var s2 pux.Output[string] = pux. MustConvertTyped[string](s1)

These functions are only useful when the user has a pu.Output or pu.AnyOutput. If they have a specific output implementation, they can also just use the ToOutput method.

var s1 pu.StringOutput    = // ...
var s2 pux.Output[string] = s1.ToOutput(context.Background())

Downgrading

Downgrading to pu.Input

We cannot support transparently passing a pux.Output[T] into a specific pu.Input because these usually take the form:

type StringInput interface {
    pu.Input

    ToStringOutput() StringOutput
    ToStringOutputPtr() StringPtrOutput
    // context variants omitted for brevity
}

It is impossible for any generic output type to implement every possible To[Name]Output method, because the set of output types isn't closed: types are generated separately for each provider SDK.

Instead, we'll rely on downgrading to the corresponding output type.
See next section.

Downgrading to pu.Output

It is possible to dynamically convert a pux.Output[T] into the corresponding output type at runtime because all output types are registered with the SDK.

We will provide an Untyped() method on pux.Output that returns the pu.Output.

func (Output[T]) Untyped() pu.Output

This will be used like so:

var s1 pux.Output[string] = // ...
var s2 pu.StringOutput    = s1.Untyped().(pu.StringOutput)

This value will be usable as both, a pu.Input and a pu.Output.

Note: A safer way to do this conversion is through the use of pux.Cast:

var s1 pux.Output[string] = // ...
var s2 pu.StringOutput    = pux.Cast[pu.StringOutput](s1)

Library compatibility

The definitions above used the names Input and Output. These are already taken in the Pulumi Go SDK by the non-generic input and output type interfaces.

To introduce the new APIs in a backwards compatible way, we have two options:

• Use different names (In and Out) and put everything in the same package. This has the benefit of making the implementation easier: pux.Output and pu.Output can access each other's internal state.
• Add the new APIs to a 'pulumix' sub-package. This is cleaner in theory, and allows the new definitions to use names closer to their final form, but it brings a fair bit of complexity in order to avoid cyclical imports. Namely, we'll have to move a fair bit of code from the pulumi package to an internal package and re-export from the pulumi package.

We recommend putting the new definitions in a 'pulumix' sub-package if possible.

This will require, at minimum, moving the following from the 'pulumi' package into an internal package and re-exporting them:

Input
Output
OutputState
ToOutput

Additionally, the pux.Input and pux.Output types, and some of their core functionality will also reside in the same internal package, re-exported from the 'pulumix' package.

This will have some negative effect on maintainers since there's an extra hoop to jump through to avoid the cyclic imports in exchange for a cleaner, more final user-facing API.

Literals

It's not uncommon to need to build output values, or pointer output values, from a literal. We will include Val and Ptr helper functions to aid in this:

func Val[T any](T) Output[T]
func Ptr[T any](T) PtrOutput[T]

Container literals

We will include an Array type for slice literals:

type Array[T any] []Input[T]

func (Array[T]) ToOutput(context.Context) Output[[]T]

// Usage:

var labels pux.Input[[]string] = pux.Array[string]{
    pux.Val("literal"), // string
    bucket.Name,        // pux.Output[string]
    oldStringOutput,    // pu.StringOutput
}

And a Map type for map literals:

type Map[T any] map[string]Input[T]

func (Map[T]) ToOutput(context.Context) Output[map[string]T]

// Usage:

var tags pux.Input[map[string]string] = pux.Map[string]{
    "createdBy": pux.Val(currentUser), // string
    "group":     bucket.Name,          // pux.Output[string]
    "whatever":  someStringOutput,     // pu.StringOutput
}

Composition

Apply2, Apply3, and more

We will include variations of Apply that accept a varying number of pux.Input arguments. The type signatures get a bit messy, but they look like the following:

func Apply2[
    T1 Input[I1],
    T2 Input[I2],
    I1, I2, O any
](T1, T2, func(I1, I2) O) Output[O]

func Apply3[
    T1 Input[I1],
    T2 Input[I2],
    T3 Input[I3],
    I1, I2, I3, O any
](T1, T2, T3, func(I1, I2, I3) O) Output[O]

// - Repeat until Apply8.
// - Add variations for context and error

These will act as type-safe replacements of pulumi.All when the number of arguments is fixed.

// Given
var a pu.IntOutput
var b pu.StringOutput

// Before
o := pu.All(a, b).ApplyT(func(vs []interface{}) string {
    a := vs[0].(int)
    b := vs[1].(string)
    return strconv.Itoa(a) + b
}).(pu.StringOutput)

// Proposed
o := pux.Apply2(a, b, func(a int, b string) string {
    return strconv.Itoa(a) + b
})

All

The previous section mentioned replacing pulumi.All with pux.Apply{2,8}. That was not entirely accurate. The pux.Apply* functions serve a different purpose than pulumi.All: they encapsulate the common use case of calling pu.All and immediately transforming the result with apply.

We still need a type-safe pulumi.All operation analog. However, it's not currently possible in Go to write a function parameterized over a variadic number of type parameters.

We'll introduce pux.All. It will operate exactly the same as the existing pu.All but with slightly more type safety: it'll expect a series of Input[any] arguments, and it will return an Output[[]any].

func All(args ...Input[any]) Output[[]any]

Note that Output[T] is not an Input[any]. To facilitate usages like this one, we'll introduce an AsAny() method on pux.Output.

func (Output[T]) AsAny() Output[any]

Example usage:

o := pux.All(
stringOutput.AsAny(),
intOutput.AsAny(),
)

pux.Apply(o, func(xs []any) string {
  s, i := xs[0].(string), xs[1].(int)
  return // ...
})

Containers

The APIs defined above are sufficient to provide a type-safe Pulumi experience. However, we are also hoping to address excessive code generation and redundant container types with this proposal.

We will generate generic output types to encapsulate pointer, array, and map outputs of any other type. These will satisfy pux.Input[...] for their corresponding container type. These types will provide convenience accessors similar to those we generate today:

type PtrOutput[T any]
  func (PtrOutput[T]) ToOutput(context.Context) Output[*T]
  func (PtrOutput[T]) Elem() Output[T]

type ArrayOutput[T any]
  func (ArrayOutput[T]) ToOutput(context.Context) Output[[]T]
  func (ArrayOutput[T]) Index(Input[int]) Output[T]

type MapOutput[T any]
  func (MapOutput[T]) ToOutput(context.Context) Output[map[string]T]
  func (MapOutput[T]) MapIndex(Input[string]) Output[T]

This alone isn't enough to replace the redundant output types, though. We need the ability to return output implementations other than Output[T] to retain the ability to chain such attribute accesses:

arrayOfUserMaps.                   // given   UserMapArrayOutput
    Index(pulumi.Int(0)).          // returns UserMapOutput
    MapIndex(pulumi.String("k")).  // returns UserPtrOutput
    EmailAddress()                 // returns StringOutput

// Equivalent to the following if they were not Output types.
//   arrayOfUserMaps[0]["k"].EmailAddress

Therefore, we will include general variants of these three output types with a second type parameter, O indicating the output implementation they should return.

Type	Satisfies	Accessor
GPtrOutput[T, O]	Input[*T]	Elem() O
GArrayOutput[T, O]	Input[[]T]	Index(Input[int]) O
GMapOutput[T, O]	Input[map[string]T]	MapIndex(Input[string]) O

O will satisfy a new constraint OutputOf[T], guaranteeing that it is an output implementation, not merely an input.

type OutputOf[T any] interface {
    Input[T]
    Output
}

Constructing container outputs

We will include the following APIs to convert Input[T] values holding pointers, arrays, or maps into the corresponding specialized generic output type:

// Input[[]T] -> ArrayOutput[T]
func NewArrayOutput[T any, I Input[[]T]](I) ArrayOutput[T]

// Input[map[string]T] -> MapOutput[T]
func NewMapOutput[T any, I Input[map[string]T](I) MapOutput[T]

// Input[*T] -> PtrOutput[T]
func NewPtrOutput[T any, I Input[*T]](I) PtrOutput[T]

Additionally, we'll include a PtrOf function to convert an existing output value into a pointer of that value. This is necessary for the frequent need where you have an Output[string] and an API expects an Input[*string].

func PtrOf[T any, O OutputOf[T]](O) GPtrOutput[T, O]

// Usage:

var name Output[string] = // ...
FooArgs{
    Name: pux.PtrOf(name), // expects an Input[*string]
}

API Summary

In summary, this proposal suggests the following new APIs.

package pulumix

//////////////////////////////////////////////////////////////////////////////
// Core types
//////////////////////////////////////////////////////////////////////////////

type Input[T any] interface {
    pulumi.Input

    // ToOutput builds an Output from this input.
    // The type T MUST match the input's ElementType.
    ToOutput(context.Context) Output[T]
}

type Output[T any] struct{ *pulumi.OutputState }

// Val builds an Output holding the given value.
func Val[T any](T) Output[T]

// ConvertTyped builds an [Output] with the given untyped output,
// returning an error if the output type does not match.
func ConvertTyped[T any](pulumi.Output) (Output[T], error)

// MustConvertTyped is a variant of [ConvertTyped] that panics
// if the output type does not match.
func MustConvertTyped[T any](pulumi.Output) Output[T]

// ToOutput returns this output back.
// This method implements Input[T].
func (Output[T]) ToOutput(context.Context) Output[T]

// Untyped converts this output into an untyped output.
// It will use the underlying type's generated Output type, if any.
func (Output[T]) Untyped() pulumi.Output

// AsAny casts the result of this output to any.
func (Output[T]) AsAny() Output[any]

// OutputOf[T] is a constraint satisfied by types that represent
// an Output[T] value.
// Besides implementing ToOutput, these types MUST
// embed *pulumi.OutputState.
type OutputOf[T any] interface {
    Input[T]
    pulumi.Output
}

//////////////////////////////////////////////////////////////////////////////
// Combinators
//////////////////////////////////////////////////////////////////////////////

// Apply transforms an output with the given function
// and returns an output containing the result.
func Apply[T Input[I], I, O any](T, func(I) O) Output[O]

// ApplyContext is a variant of [Apply] that uses the context
// to control the lifetime of the operation.
func ApplyContext[T Input[I], I, O any](context.Context, T, func(I) O) Output[O]

// ApplyErr is a variant of [Apply] that allows the function to fail.
// If the function returns an error, the returned output
// and all its derived values will fail.
func ApplyErr[T Input[I], I, O any](T, func(I) (O, error)) Output[O]

// ApplyContextErr is a variant of [ApplyErr] that uses the context
// to control the lifetime of the operation.
func ApplyContextErr[T Input[I], I, O any](context.Context, T, func(I) (O, error)) Output[O]

// Apply2-8 combine and transform the output of 2-8 inputs
// using the given function.
func Apply2[...](T1, T2, func(I1, I2) O) Output[O]
func Apply3[...](T1, T2, T3, func(I1, I2, T3) O) Output[O]
// ...
func Apply8[...](T1, ..., T8, func(I1, ..., I8) O) Output[O]
// These include context, error, and context+error variants:
//
//   func Apply2Context[...](context.Context, ...) Output[O]
//   ...
//   func Apply8Context[...](context.Context, ...) Output[O]
//
//   func Apply2Err[...](..., func(...) (O, error)) Output[O]
//   ...
//   func Apply8Err[...](..., func(...) (O, error)) Output[O]
//
//   func Apply2ContextErr[...](context.Context, ..., func(...) (O, error)) Output[O]
//   ...
//   func Apply8ContextErr[...](context.Context, ..., func(...) (O, error)) Output[O]

// Join flattens an output contained inside another output
// into a single output.
func Join[O any, I Input[Output[O]]](I) Output[O]

// JoinContext is a variant of [Join] that accepts a context.
func JoinContext[O any, I Input[Output[O]]](context.Context, I) Output[O]

//////////////////////////////////////////////////////////////////////////////
// Pointers
//////////////////////////////////////////////////////////////////////////////

// GPtrOutput holds a pointer to a value of type T.
type GPtrOutput[T any, O OutputOf[T]] struct{ *pulumi.OutputState }

// PtrOf builds an Output holding a pointer to the value
// contained in the provided input.
func PtrOf[T any, O OutputOf[T]](O) GPtrOutput[T, O]

// Elem dereferences the value inside this output
// and returns it as a specialized output type O.
func (PtrOutput[T, O]) Elem() O

func (PtrOutput[T, O]) ToOutput(context.Context) Output[*T]

// PtrOutput holds a pointer to a value of type T.
type PtrOutput[T any] struct{ *pulumi.OutputState }

// Ptr builds an Output holding a pointer to the given value.
func Ptr[T any](T) PtrOutput[T]

// Elem dereferences the value inside this output
// and returns it as an output.
func (PtrOutput[T]) Elem() Output[T]

func (PtrOutput[T]) ToOutput(context.Context) Output[*T]

//////////////////////////////////////////////////////////////////////////////
// Arrays
//////////////////////////////////////////////////////////////////////////////

// GArrayOutput is an output holding a list of values of type T.
type GArrayOutput[T any, O OutputOf[T]] struct{ *pulumi.OutputState }

func (ArrayOutput[T, O]) ToOutput(context.Context) Output[[]T]

// Index returns the item in this array at the given position
// as an output of special type O.
func (GArrayOutput[T, O]) Index(Input[int]) O

// ArrayOutput is an output holding a list of values of type T.
type ArrayOutput[T any] struct{ *pulumi.OutputState }

// NewArrayOutput builds an array output from an input
// that holds a slice of values.
func NewArrayOutput[I Input[[]T], T any](I) ArrayOutput[T]

// All builds an array output that will yield a slice of values
// for each of the given inputs in the same order.
func All(inputs ...Input[any]) ArrayOutput[any]

// Index returns an output holding the value at the given index in the array.
// The output waits until the index value is available.
// The output fails if the index is out of bounds.
func (ArrayOutput[T]) Index(Input[int]) Output[T]

func (ArrayOutput[T]) ToOutput(context.Context) Output[[]T]

// Array is a list of input values of the same type.
// It may be used as an Input[[]T].
type Array[T any] []Input[T]

func (Array[T]) ToOutput(context.Context) Output[[]T]

//////////////////////////////////////////////////////////////////////////////
// Maps
//////////////////////////////////////////////////////////////////////////////

// GMapOutput is an output holding a mapping
// from string to values of the given type.
type GMapOutput[T any, O OutputOf[T]] struct{ *pulumi.OutputState }

func (GMapOutput[T, O]) ToOutput(context.Context) Output[map[string]T]

// MapIndex returns an output holding the value with the given key in the map
// wrapped inside output type O.
func (GMapOutput[T], O) MapIndex(key Input[string]) O

// MapOutput is an output holding a mapping
// from string to values of the given type.
type MapOutput[T any] struct{ *pulumi.OutputState }

// NewMapOutput builds a MapOutput from an input
// that holds a map of values.
func NewMapOutput[I Input[[]T], T any](I) MapOutput[T]

// MapIndex returns an output holding the value with the given key in the map.
// The output waits until the key value is available.
// The output holds a zero value of T if the key is not in the map.
func (MapOutput[T]) MapIndex(key Input[string]) Output[T]

func (MapOutput[T]) ToOutput(context.Context) Output[map[string]T]

// Map is a map from string to input values of the same type.
// It may be used as an Input[map[string]T].
type Map[T any] map[string]Input[T]

func (Map[T]) ToOutput(context.Context) Output[map[string]T]

It additionally proposes that:

• all types in the core Pulumi SDK implement ToOutput
• SDK generation be changed to include a ToOutput method on all input and output types

Off-ramp

This section discusses how we'll be able to use the new APIs to slowly transition from untyped to typed APIs.

To off-ramp from untyped APIs to type-safe APIs across the ecosystem, we'll have the following phases.

• Generics rollout: No breaking changes. End users will mix type-safe and untyped code.
• Provider migration: Providers that are ready for it will bump their major versions and opt into new definitions in their public APIs.
• Pulumi v4: When Pulumi is ready for it, we delete untyped APIs in favor of the typed ones.

These phases are discussed in more detail below.

Phase 1: Generics rollout

During this phase, we will release the proposed APIs into the Pulumi Core SDK. In the same release, we will change the SDK generator to include ToOutput methods for generated concrete types. Individual providers will pick up this new functionality as they update to the latest Pulumi release. Once all known providers are on this release, we may optionally deprecate (but not delete) the untyped APIs.

Note that this is entirely backwards compatible. For example, consider aws/s3. With these changes, the package will look exactly the same except methods like the following will be added where relevant:

func (*AcessPoint) ToOutput(context.Context) pux.Output[*AccessPoint]
func (*AccessPointArgs) ToOutput(context.Context) pux.Output[*AccessPoint]
func (AccessPointArray) ToOutput(context.Context) pux.Output[[]*AccessPoint]
func (AccessPointArrayOutput) ToOutput(context.Context) pux.Output[[]*AccessPoint]
func (AccessPointMap) ToOutput(context.Context) pux.Output[map[string]*AccessPoint]
func (AccessPointMapOutput) ToOutput(context.Context) pux.Output[map[string]*AccessPoint]
func (AccessPointOutput) ToOutput(context.Context) pux.Output[*AccessPoint]

This will be sufficient for end users of Pulumi to begin using pux.Apply and friends with these types.

Phase 2: Provider migration

Commencement of this phase is contingent on the following:

• All supported providers have upgraded to the new version of Pulumi. This will generate ToOutput methods for all their input and output types.
• We have settled on how we want struct outputs to be represented. There are two options here: the current way, and the one proposed in Directly accessible output struct fields.

In this phase, providers that are willing to accept a breaking change in their public APIs will opt into the new definitions by activating a flag on the SDK generator. With this flag enabled, the SDK generator will change all generated APIs to accept pux.Input types, and return pux.Output or pux.[G]{Array,Map,Ptr}Output values.

Migrating provider outputs

Going back to the S3 example, s3.AccessPoint will produce pux.Output[string], pux.Output[bool], etc. instead of its current output fields.

 type AccessPoint struct {
-    AccountId pu.StringOutput `pulumi:"accountId"`
+    AccountId pux.Output[string] `pulumi:"accountId"`
     // ...
-    Endpoints pu.StringMapOutput `pulumi:"endpoints"`
+    Endpoints pux.MapOutput[string] `pulumi:"endpoints"`
     // ...
-    HasPublicAccessPolicy pu.BoolOutput `pulumi:"hasPublicAccessPolicy"`
+    HasPublicAccessPolicy pux.Output[bool] `pulumi:"hasPublicAccessPolicy"`
     // ...
 }

Note: This example omits fields that hold struct output values. See the next section for more information on them.

This is a breaking change to the AccessPoint struct. The types of its fields have changed. At least the following sites will require updating:

• Direct references to the field types. For example:

  -func accountId(ap *s3.AccessPoint) pu.StringOutput {
  +func accountId(ap *s3.AccessPoint) pux.Output[string] {
      return ap.AccountId
   }

• Passing these fields as input to APIs that haven't switched to the new APIs. For instance, suppose command/local has yet to switch and expects a pu.StringPtrInput for one of its fields. We'll have to use the pux.Cast function. (See Downgrading for details.)

   var obj *s3.BucketObject = // ...
   cmd, err := local.NewCommand(ctx, name, &local.CommandArgs{
       // ...
  -    Stdin: obj.Content,
  +    Stdin: pux.Cast[pu.StringPtrOutput](obj.Content),
   })

Existing Output.ApplyT calls to these fields will require no changes.

count := ap.Endpoints.ApplyT(func(m map[string, string]) int {
    return len(m)
})

Migrating provider output structs

The example above did not include output structs. We'll discuss those here. Pulumi currently generates convenience accessors for output structs--see Struct data in v3 for details. We don't want to lose the ability to use these accessors.

Therefore, we will continue to generate output types for struct types. However, we will use the GPtrOutput, GMapOutput, and GArrayOutput types defined above for all containers.

For example:

type AccessPoint struct {
    // ...

    VpcConfiguration pux.GPtrOutput[AccessPointVpcConfiguration, AccessPointVpcConfigurationOutput]
}

var ap AccessPoint = // ...
ap.VpcConfiguration.
    Elem(). // returns an AccessPointVpcConfigurationOutput
    VpcId() // returns Output[string]


type Bucket struct {
    // ...
    Objects pux.GArrayOutput[BucketObject, BucketObjectOutput]
}

var b Bucket = // ...
b.Objects.
  Index(idx). // returns BucketObjectOutput
  Acl().      // returns pux.PtrOutput[string]
  Elem()      // returns pux.Output[string]

Alternatively, there's an opportunity here to replace accessor methods with direct attribute access. See Directly accessible output struct fields.

Migrating provider inputs

Similarly to the outputs, points where the SDK previously accepted built-in or generated input types, it will expect pux.Input types.

For instance:

 type AccessPointArgs struct {
-     AccountId pu.StringPtrInput
+     AccountId pux.Input[*string]
      // ...
-     Bucket pu.StringInput
+     Bucket pux.Input[string]
      // ...
-     VpcConfiguration AccessPointVpcConfigurationPtrInput
+     VpcConfiguration pux.Input[*AccessPointVpcConfiguration]
 }

The same change will be made to other structs and functions that accept input values. This is a breaking change, and any direct references to the types of these fields will need to be updated.

However, most assignments to these fields will require no changes because both, old output types (pu.StringPtrOutput) and new output types (pux.Output[*string]) will satisfy the corresponding input interface (pux.Input[*string]), and therefore be assignable to those fields as-is.

Phase 3: Pulumi v4

When at some future date, we're willing to make a breaking change to Pulumi, we will delete a bulk of the old APIs defined in the top-level pulumi package. At least types with names matching the following regular expressions will be deleted:

.*Array
.*Map
.*Output
.*Input

The Input and Output types in particular will be replaced by their type-safe generic variants.

This will be accompanied by a matching change to the code generators.

Future work

This section lists extensions we could add on top of the proposed APIs with varying levels of confidence on each item.

Apply2, Apply3, and friends for other SDKs

To keep the high-level operations consistent across SDKs, we'll introduce analogs of pux.Apply2, pux.Apply3, and the rest to other SDKs. These will act as a shortcut over the all(...).apply(...) pattern:

pulumi.all({a, b, c}).apply(({a, b, c}) => { ... })
// versus
pulumi.apply({a, b, c}, ({a, b, c}) => { ... })

The design of this functionality for other SDKs is out of scope for this document.

Type-safe output specialization

To implement some of the functionality defined above, we'll need a function that is able to upgrade an Output[T] into an arbitrary output type O as long as it satisfies OutputOf[T]. Let's refer to this as cast for now:

func cast[
    O OutputOf[T],
    T any,
](Output[T]) O

As an example, this function is used in GPtrOutput like so:

func (o GPtrOutput[T, O]) Elem() O {
    result := Apply(o, func(v *T) T { /* ... */ })
    // TypeOf(result) == Output[T]

    return cast[O](result)
}

This function is likely to be valuable to users to perform type-safe upgrades and downgrades during Phase 1 where they have code mixing the typed and untyped APIs.

For example:

var s1 pux.Output[string] = // ...
s2 := cast[pu.StringOutput](s1)

We should consider exporting this function as pux.Cast.

Directly accessible output struct fields

See Structured data in v3 for what we currently do for struct output types.

@AaronFriel suggested an alternative representation for output structs which would obviate the need for accessor methods. Since we get only one chance to make a breaking change to how outputs are consumed, we should consider bundling this change in with Phase 2.

In short, the idea is that instead of generating standard output types that embed *OutputState, we will flatten all nested structs so that only primitive and container fields use actual output types.

For example, we currently plan on generating the following after this proposal:

type Bucket struct {
    // ...
    Bucket pux.Output[string] `pulumi:"bucket"`
    Grants pux.GArrayOutput[BucketGrant, BucketGrantOutput] `pulumi:"grants"`
    Website pux.GPtrOutput[BucketWebsite, BucketWebsiteOutput] `pulumi:"website"`
}

// Where:

type BucketWebsiteOutput struct{ *pu.OutputState }

func (BucketWebsiteOutput) ToOutput(context.Context) pux.Output[BucketWebsite]

func (BucketWebsiteOutput) IndexDocument() pux.Output[*string]

Instead, we would generate the following:

type Bucket struct {
    // ...
    Bucket pux.Output[string] `pulumi:"bucket"`
    Website pux.PtrOutput[BucketWebsite, BucketWebsiteOutput] `pulumi:"website"`
}

// Where:

type BucketWebsiteOutput struct {
    IndexDocument pux.Output[*string]
}

func (BucketWebsiteOutput) ToOutput(context.Context) pux.Output[BucketWebsite]

This will allow direct access to fields of the various structs.

var b Bucket = // ...
index := b.Website.Elem().IndexDocument

Some details remain to be ironed out here, but we should give this full consideration before we make any code generation changes.

Array and Map Filtering

We can introduce Filter methods to the pux.ArrayOutput and pux.MapOutput types.

func (ArrayOutput[T]) Filter(keep func(i int, v T) bool) ArrayOutput[T]

func (MapOutput[T]) Filter(keep func(k string, v T) bool) MapOutput[T]

These will return new equivalent output types with only those items in them for which keep returned true.

Type-safe tuples

To augment pux.All for a fixed number of parameters, we should consider adding functions All[N] functions for N 2-8. These will return Tuple[N]Output objects holding Tuple[N] values. For example:

type Tuple2[T1, T2 any] struct {
    V1 T1
    V2 T2
}

type Tuple2Output[T1, T2 any] struct{ *OutputState }

func (Tuple2Output[T1, T2]) V1() Output[T1]
func (Tuple2Output[T1, T2]) V2() Output[T2]

func (Tuple2Output[T1, T2]) ToOutputT(context.Context) Output[Tuple2[T1, T2]]

func All2[
T1, T2 any,
I1 InputT[T1],
I2 InputT[T2],
](i1 I1, i2 I2) Tuple2Output[T1, T2] 

The above gives us a means of grouping a pair of input values into a single output value in a type-safe manner. Keeping with the pattern of Apply2 and friends, we will generate variants of this up to 8 in the core Pulumi SDK.

Type-safe output composition

As an alternative to Type-safe tuples, @t0yv0 shared a prototype from prior experimentation as inspiration.

He suggested a callback-based API that allows composition of an arbitrary number of outputs. Roughly, the new API surface would be:

func Compose[T any](context.Context, func(*O) (T, error)) Output[T]

type O struct{/* unexported fields */}

func Await[I Input[T], T any](*O, I) (T, error)

Key details:

• Compose accepts a callback over an opaque type *O
• Await accepts an *O and an input value, and returns its result
• *O internally tracks output state for the result of Compose

Together, these allow arbitrarily complex composition of output values. For example:

var (
    name    pux.Output[string]      = // ...
    tags    pux.ArrayOutput[string] = // ...
    buckets []pux.Output[*Bucket]   = // ...
)
pux.Compose(ctx, func(o *pux.O) (*SomeStruct, error) {
    name, err := pux.Await(o, name)
    // TypeOf(name) = string
    if err != nil {
        return nil, err
    }

    tags, err := pux.Await(o, tags)
    // TypeOf(tags) = []string
    if err != nil {
        return nil, err
    }

    var bs []*Bucket
    for _, bout := range buckets {
        b, err := pux.Await(bout)
        // TypeOf(b) = *Bucket
        if err != nil {
            return nil, err
        }
        bs = append(bs, b)
    }

    return &SomeStruct{
        Name:    name,
        Tags:    tags,
        Buckets: bs,
    }, nil
})

Some details about how this would work are unclear at this time.

FAQ

Why embed OutputState instead of Output?

The marshaling logic requires that the OutputState type be embedded into custom output types. This is fixable, but even without this restriction, there's some additional flexibility afforded by not requiring types to embed a typed output.

Can we delete the Input type?

We've eliminated the Input type in the Java SDK, but we cannot do the same for Go as part of this redesign.

The Input[T] provides us with polymorphism on the kinds of values we'll accept in place of an Output[T]. This facilitates at least the following features:

• We allow upgrading StringOutput to pux.Output[string] transparently.

• We're able to provide type-safe container types.

• We can leverage composite literals for containers.

• We give users flexibility to define their own helpers. For example, a user could write:

  type MyOutput struct{ *OutputState }
  
  func (MyOutput) ToOutput(context.Context)

Why is Input a type constraint for Apply and friends?

In Apply and similar functions, we use Input[I] as a type constraint. That is, we do the following:

func Apply[T Input[I], I, O any](T, func(I) O) Output[O]

However, the following is also a valid way to write Apply. It treats Input[T] as a type.

func Apply[I, O any](Input[I], func(I) O) Output[O]

We chose the former because it allows the type system to infer the value of type parameter I from the type of the input value.

If we chose the latter form, Go's type system will not infer type parameter I, and users will have to set it manually:

Apply[int](intInput, func(i int) string { /* ... */ })

(This may improve in future versions of Go, e.g. with golang/go#58650.)

Why don't we use generics to have a single Apply function?

It's possible with generics to write a single Apply function that accepts both, fallible and infallible appliers.

type Fn[I, O any] interface {
    func(I) O |
    func(I) (O, error)
}

func Apply[T Input[I], F Fn[I, O], I, O any](i T, f F) Output[O] {
    switch any(f).(type) {
    case func(I) O:
        // ...
    case func(I) (O, error):
        // ...
    default:
        unreachable()
    }
}

Unfortunately, this leaves the type system insufficient information in any invocation of Apply to infer the types of I and O in a simple call like the following:

var so Output[string] = // ...

// ERROR: Cannot infer O
Apply(so, func(s string) int { return len(s) })

Simplifying this further—no input constraint—even the following is insufficient:

func Apply[I, O any, F Fn[I, O]](I, F) (O, error)

// ERROR: Cannot infer O
Apply("foo", func(s string) int { return len(s) })

// OK
Apply[string, int](so, func(s string) int { return 42 })

If we invert the constraints to move O first and set it, that is sufficient:

func Apply[O, I any, F Fn[I, O]](I, F) (O, error)

Apply[int](so, func(s string) int { return 42 })

However, the inconvenience of having to supply the type name repeatedly outweighs the benefit of this overloading—it's not much better than casting the output of ApplyT.

Apply[int](so, func(s string) int { return 42 })

so.ApplyT(func(s string) int { return 42 }).(IntOutput)

Why are Join's type parameters out of order?

Go's type inference is currently unable to infer its type in a snippet like the following:

var x Output[Output[[]int]]
o := Join(x) // ERROR: cannot infer O

Since the type parameter is required anyway, we make the function's usage slightly easier by making it the first parameter. A caller will be able to use it after supplying just that parameter, and not I.

var x Output[Output[[]int]]
o := Join[[]int](x) // good
o := Join[[]int, Output[Output[[]int]]](x) // okay, but unnecessary

Why do we need GPtrOutput and friends?

The GPtrOutput, GArrayOutput, and GMapOutput types are necessary so that accessor methods know the kind of value to return. Without this, we would lose the ability to chain these outputs together.

For example, suppose that we drop these types and have just the plain variants:

type PtrOutput[T any]
type ArrayOutput[T any]
type MapOutput[T any]

Their accessors return Output[T]:

func (PtrOutput[T]) Elem() Output[T]
func (ArrayOutput[T]) Index(Input[int]) Output[T]
func (MapOutput[T]) MapIndex(Input[string]) Output[T]

Given a list of maps, we will be unable to chain these calls:

var arr pux.ArrayOutput[map[string]int]
arr.
  Index(idx). // returns Output[map[string]int]
  MapIndex(k) // error: Output[T] has no method MapIndex

Compare that with the two-parameter version which is able to do this:

var arr pux.GArrayOutput[map[string]int, pux.MapOutput[int]]
arr.
  Index(idx). // returns pux.MapOutput[int]
  MapIndex(k) // returns Output[int]
// success!

Appendix

Hackathon prototype

The prototyped API that came out of a prior Hackathon for introducing generics to the Go SDK can be minimized to the following:

It added a new Promise type.

// Promise is a promise of a value of type T.
// Promise is both an Input and an Output.
type Promise[T any] struct{ *OutputState }

This would act as both, an Input and an Output for the type T.
It includes the following basic operations for type-conversion.

// Cast converts an Output into a Promise.
func Cast[T any](Output) Promise[T]

// T converts an arbitrary value into a Promise.
// It's an alias for a top-level ToPromise function.
func T[T any](T) Promise[T]

flowchart LR
    PromiseT["Promise[T]"]
    T -->|ToPromise| PromiseT
    Output -->|Cast| PromiseT

    PromiseT -.-|is a| Input & Output2["Output"]

The OutputState.ApplyT method is turned into a top-level function because Go doesn't support method-level generics, and a FlatMap function is added for functions which return promises.

// Apply returns a new Promise that holds the result
// of applying the given function to the given Promise.
func Apply[T, U any](Promise[T], func(T) U) Promise[U]

// FlatMap returns a new Promise that holds the result
// of applying the given function to the given promise.
func FlatMap[T, U any](Promise[T], func(T) Promise[U]) Promise[U]

// Err and Context variants omitted for brevity.

flowchart LR
    PromiseT["Promise[T]"]
    PromiseU["Promise[U]"]
    
    subgraph Apply
        f1["func(T) U"]
    end
    subgraph FlatMap
        f2["func(T) Promise[U]"]
    end

    PromiseT --> Apply --> PromiseU
    PromiseT --> FlatMap --> PromiseU

Other functions included in the prototype have been omitted as most of them can be constructed from the functions defined above.

Concepts in v3

This section summarizes the core concepts (Input, Output, and Apply) as they are in Pulumi Go v3. Some details have been omitted for brevity.

The Input and Output interfaces are defined as follows.

type Input interface {
    ElementType() reflect.Type
}

type Output interface {
    ElementType() reflect.Type
    ApplyT(applier interface{}) Output

    getState() *OutputState
}

Custom outputs

The OutputState struct holds most of the implementation of an Output—all but the ElementType.

type OutputState struct{ /* unexported fields */ }

func (*OutputState) getState() *OutputState
func (*OutputState) ApplyT(interface{}) Output

For any type meant to be passed as an output, a user—or more often, a code generator—writes a new struct type that embeds *OutputState. Embedding creates delegates of all methods on OutputState on this struct, and it implement ElementType separately. For example:

type StringOutput struct{ *OutputState }

func (StringOutput) ElementType() reflect.Type {
    return reflect.TypeOf("")
}

Each such output type is registered with the Pulumi SDK using RegisterOutputType.

func init() {
    RegisterOutputType(StringOutput{})
}

This registration information is used by functions like ToOutput and methods like ApplyT to decide the output implementation they should return for a given type.

Custom inputs

To implement an input type, the system generates an interface that embeds Input, and includes a To[Type]Output method, as well as their context and pointer variants if appropriate.

type StringInput interface {
    Input

    ToStringOutput() StringOutput
    ToStringPtrOutput() StringPtrOutput
}

Input types are similarly registered with the Pulumi SDK with the RegisterInputType˙ function.

func init() {
    RegisterInputType(reflect.TypeOf((*StringInput)(nil)).Elem(), String(""))
}

Outputs of outputs

Output.ApplyT eagerly unwraps outputs nested inside output values: if the applier function returns an output value, it unwraps it.

out := stringOutput.ApplyT(func(s string) IntOutput {
    // ...
}).(IntOutput)

Note that the result is an IntOutput, not an AnyOutput value containing an IntOutput value.

Structured data in v3

Pulumi's SDK generator generates output types for every new type, pointer, and collection it encounters. In these output types, it includes convenience methods to access their sub-items as output-wrapped values.

For structs, it generates an output type with field accessors. For example:

type AccessPoint struct {
    AccountId             string
    HasPublicAccessPolicy bool
    VpcConfiguration      *AccessPointVpcConfigurationPtr
}

type AccessPointOutput struct{ /* ... */ }

func (AccessPointOutput) AccountId() pu.StringOutput
func (AccessPointOutput) HasPublicAccessPolicy() pu.BoolOutput
func (AccessPointOutput) VpcConfiguration() AccessPointVpcConfigurationPtrOutput

For pointer types, it generates an analog of the struct output type:

type AccessPointPtrOutput struct{ /* ... */ }

func (AccessPointPtrOutput) AccountId() pu.StringOutput
func (AccessPointPtrOutput) HasPublicAccessPolicy() pu.BoolOutput
func (AccessPointPtrOutput) VpcConfiguration() AccessPointVpcConfigurationPtrOutput

For arrays, it generates an output type with an Index method to access specific positions in the array.

type AccessPointArrayOutput struct{ /* ... */ }

func (AccessPointArrayOutput) Index(pu.IntInput) AccessPointOutput

For maps, it generates an output type with a MapIndex method.

type AccessPointMapOutput struct{ /* ... */ }

func (AccessPointMapOutput) MapIndex(pu.StringInput) AccessPointOutput

Note that because maps and arrays return the specialized output type for that struct, users are able to perform chained access:

var aps AccessPointArrayOutput = ...

vpcId := aps.Index(pu.Int(0)).VpcConfiguration().VpcId()

Edits

• Renamed pux.[Must]Cast to pux.[Must]ConvertTyped and renamed pux.SpecializeOutput to pux.Cast.
• Updated content to prefer the safer pux.Cast[pu.StringOutput](o) over o.Untyped().(pu.StringOutput)

[marco-m]

hello @abhinav, I would like to express my admiration for this RFC, not only for the proposed approach, but also for how thoughtfully and clearly its has been written. It is a pleasure to read. This will be a great improvement indeed. Keep up the good work! Kudos!

[danielrbradley]

@abhinav I think we should include unions in this design to bring Go up to the same safety and usability of other supported languages.

The most obvious approach would be to replicate the union types from dotnet. These have the downside of being slightly clunky to work with but would be completely safe. If there's plans to support discriminated unions within Go then perhaps we should consider waiting for that.

My expectations would be that either of these approaches would be a breaking change to introduce from the current untyped approach because they would require a user to change their program's code. I don't think there'd be an easy way to make it backward compatible.

We should therefore consider including this as part of the Generics rollout because introducing a later breaking change will be quite difficult to roll-out.

[abhinav]

I'm not certain that that's the best option here.

First, I don't think unions should be considered in scope for the generics discussion. It's an adjacent limitation of the Pulumi Go SDK, and not something generics can fix¹. The existence of generic Input and Output types can make it easier to improve unions, but I don't think doing so should be considered a blocker for generics. Although, I agree that it's tempting to attempt to bundle as many fixes as possible as part of the potential breaking change².

Regarding breaking changes: yes, it would be a breaking change to modify how unions are implemented. However, depending on the route we take, it could be "all code that uses unions must be updated" or it could be "valid code remains unchanged, and invalid code that previously compiled but failed to run now fails to compile." Based on our usage contracts here, I would argue that the latter is acceptable and shouldn't necessarily be considered a breaking change—working code remains working, and broken code just fails with a different error much sooner.

Lastly, on how we would fix unions: I don't think .NET approach is the best option we have. As you pointed out, Union[Union[Union[A, B], C], D] would be quite cumbersome to use. I think a sealed interface would be a better approach. For background, a sealed interface is an interface with an unexported marker method (e.g. type Foo interface{ foo() }). Only types in the package that defines the interface can implement that interface. This gives you an exhaustive list of types that satisfy some interface. This is how Protobuf in Go implements oneof. I haven't explored this fully, but regardless, this should be a separate discussion.

Footnotes

1. Type constraints do support specifying a list of types (e.g. type Foo interface{ A | B | C }) but constraints cannot be used as struct field types (e.g. type Bar struct{ X Foo } is invalid). The struct has to be parameterized over the constraint (type Bar[F Foo] struct{ X F }) which makes this a non-starter for this purpose—adding new type parameters to a struct is a breaking change. There are no ongoing plans to address this; all related issues are currently on hold (golang/go#57644, golang/go#45380, golang/go#19412). ↩

2. Note that current plans do not include a real breaking change at this time. ↩

[danielrbradley]

Yup, I agree that generating sealed classes for each specific union would be nicer that dotnet's generic approach.

The core problem around the descriminated unions is the usability. When presented with the SDK it's nearly impossible to know what type to select. On reflection I think we can address this issue more pracmatically by just generating a documentation comment on the property which lists the expected types. This could also be extended to every input property to demonstrate how to set the field using things like the pulumi.String() helpers correctly.

[danielrbradley]

I've filed #13775 to focus on improving the usability of Go for both DUs and normal resource arguments.

[ringods]

Hello all, the initial implementation of our Go Generics support has landed in v3.80.0. See the release notes in #13855

[justinvp]

Note that the v3.80.0 release contains the necessary core SDK support for Go Generics. We will be sharing our plan for rolling out Go Generics support (in a compatible way) to provider SDKs in the coming weeks.