Simple array types in parameters and outputs

[majastrz]

Current

Current syntax for parameters and outputs allows the user to specify array as the type. This type is equivalent to any[] type in TS (each item can be of any other type and each item can be of a different type).

Proposal

Allow the user to declare the item type for arrays of bool, string, and int types.

Non-Goals

There exists a separate problem of user-defined object types. This proposal does not attempt to address that at all.

Examples

Simple one-level arrays could look like this:

parameter myStringArray string[]
parameter myIntArray int[]
output myBoolArray bool[] = <expression>

Nesting would be allowed and would look like the following:

parameter myArrayOfStringArrays string[][]
parameter myArrayOfIntArrays int[][]
output myArrayOfBoolArrays bool[][] = <expression>

Compiled JSON

These narrower array types do not exist in JSON. We would compile them all to array type until JSON supports those types. Until then, there would be no runtime checking for this. When referencing bicep modules, bicep would be able to use the enhanced type information to produce better/more errors.

In the native module case (referencing a compiled or hand-written JSON template), bicep would have to fall back to any[] type unless the extra metadata needed can be embedded in the JSON.

[PietervdWerk]

This would indeed increase validation possibilities like catching a simple error like below. The array is a one-dimensional array, while the module tries to access the second dimension and would therefore fail at deployment.

param environments string[]

module KeyVaults '../any/key-vault.bicep' = [for (environment, i) in environments: {
  name: 'key-vault-${environment[i]}'
  params: {
    ProductName: 'ProductName'
    Environment: environment[i]
  }
}]

[anthony-c-martin]

Closing as this is covered by the "user defined types" work.