This message was deleted.

Output<T>

denotes that the underlying value relies on some asynchronous work

Input<T>

accepts constants, literals, or

Output<T>

because it conveys that the input should wait on the asynchronous work If your function parameter accepts

Input<T>

than you could freely pass it literals, values that are known at compile time, or `Output<T>`s If your function parameter accepts

Output<T>

and you want to pass a string literal or value otherwise known at compile time, than you would need to do something like

Output.Create(() => "literal"))

or

Output.Create("literal")

which is a bit silly to create what is essentially a promise for a synchronous function/value when it wouldn't otherwise be necessary if your function accepted

Input<T>

So Input shows it should wait for the output being passed in and Output shows it should retain the meta data associated with the output. In my specific case I’m passing outputs from other resources into parameters as outputs and didn’t know if I should be passing the outputs into and input argument on a method. I hope that makes sense and I understand correctly.

So Input shows it should wait for the output being passed in and Output shows it should retain the meta data associated with the output.

I'm not really understanding this interpretation. An

Output<T>

denotes an asynchronously acquired value. It will have dependency metadata if it comes from a resource, but it does not always have dependency metadata - because you can make outputs freely if you wish. An

Input<T>

can be passed anything, and it is just smart enough to know that if it is passed an

Output<T>

it will need to

await

the underlying promise/task. I would make your parameters accept

Input<T>

.

Okay sorry if I wasn’t understanding clearly or communicating well, but I think you cleared it up about making parameters accept Input<T>. Thank you! This was very helpful.

No worries just wanted to make sure I wasn't being unintentionally confusing. Good luck!