[Feature request] allow the return value of an function call to be used behind the = of a resource definition

[chris-kruining]

I couldn't think of nice title, and it is also pretty vague. But an example will show me properly what I am looking for.

currently I do this (staticWebApp is a function from a registry which provides config conform our conventions):

var appConfig = staticWebApp(context)
resource app 'Microsoft.Web/staticSites@2023-01-01' = {
  name: appConfig.name
  identity: appConfig.identity
  location: appConfig.location
  tags: appConfig.tags
  sku: appConfig.sku
  properties: appConfig.properties
}

what I'd like to do is this:

resource app 'Microsoft.Web/staticSites@2023-01-01' = staticWebApp(context)

[ahelland]

Someone is thinking like a programmer :)

I see what you mean, but wouldn't this easily turn into "hiding" things and make the Bicep code less readable? Sure, with Intellisense in VS this isn't a problem, but with Bicep being a compile-time language it's slightly different.

[chris-kruining]

well, the problem is that I am already hiding things. the function already returns an object. so the dev using the function has to basically guess what properties exist on that variable, so it is a total black box. and the thing is, the object returned is pretty composable, I've not shown that yet in my example above, but you can do this:

var appConfig = staticWebApp(context, [
  withDefaultSku()
  withManagedIdentity()
])
resource app 'Microsoft.Web/staticSites@2023-01-01' = {
  name: appConfig.name
  identity: appConfig.identity
  location: appConfig.location
  tags: appConfig.tags
  sku: appConfig.sku
  properties: appConfig.properties
}

so I either want to make transparent what properties exist on that returned object so it is no longer a black box.
or be able to assign the return value of the function to the resource so that the dev at least won't be confronted with the black box,

[ahelland]

hmm...

I don't have the same use case myself at the moment, but makes more sense. If I do the infra bits I don't want too much hidden things going on. But I do of course wrap things in modules anyways. The developers consuming the more app centric modules (Container Apps, SQL Databases, etc.) don't care as long as the params they are interested in are visible to them when wiring into their pipelines.