This message was deleted.

sparse-intern-71089

04/19/2019, 10:33 PM

This message was deleted.

incalculable-diamond-5088

04/19/2019, 10:51 PM

Seems like it was a problem in my code. Though theoretically it can happen?

white-balloon-205

04/19/2019, 11:28 PM

I think the idea is that the caller should only pass a value at all for one or the other. Technically this doesn't support passing

Output<undefined>

for one and

Output<defined>

for the other, but that ideally shouldn't be a common use case.

white-balloon-205

04/19/2019, 11:29 PM

Curious if @lemon-spoon-91807 or @breezy-hamburger-69619 have thoughts on this general pattern.

lemon-spoon-91807

04/19/2019, 11:30 PM

Right. only one should be set. Though i am curious why these are outputs. @breezy-hamburger-69619 In general we discourage Output<Resource>. Is that necessary here?

breezy-hamburger-69619

04/19/2019, 11:35 PM

Taking a 2nd look @ it, I don’t believe it is necessary. I adopted the

Output<Resource>

for

instanceRoles

as I found

instanceRole

to be an

Output

so i followed suit. This should be type itself, not outputted

white-balloon-205

04/19/2019, 11:37 PM

Input<Resource> is a holdover for an old design pattern here. Hard to change now. But that's a bit orthogonal to the question I was asking (about using

&&

on two "optional Input<T>" arguments). But not a big deal.

Open in Slack

Previous Next

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.