Nullable types

[jeskew]

Resolves #8973 and resolves #8807

This PR adds a ? type postfix operator that identifies any type expression as nullable, meaning that in addition to values matching the unmodified type, a missing or explicit null value will be accepted.

For example, the following statement will declare a parameter, foo, for which a deployment may submit a string, an explicit null, or no value or at all:

param foo string?

For the consumer of a template, a nullable param is indistinguishable from a regular param with a default value. For the example of foo above, the experience of deploying the containing template is the same as if it had been declared with a default value (param foo string = ''). In both cases, the foo param is optional, and a string, a null, or no value at all will be accepted at deployment time.

Template authors should use a nullable parameter when they are not responsible for deciding what to do in case a param is omitted. A good use case is when a module has an optional param and it is the module's responsibility to assign a default. For example, in the following set of templates, main.bicep serves as an orchestrator, mod.bicep deploys a subsystem, and storage.bicep is a utility module that deploys a storage account:

main.bicep

param modStorageAccountName string?

module mod './mod.bicep' = {
  name: 'mod'
  params: {
    storageAccountName: modStorageAccountName
  }
}

mod.bicep

param storageAccountName string = 'modsa'

module storage './storage.bicep' = {
  name: 'storage'
  params: {
    accountName: storageAccountName
  }
}

storage.bicep

param accountName string

resource sa 'Microsoft.Storage/storageAccounts@2021-08-01' = {
  name: accountName
  ...
}

Because nullable params are meant to provide a means of making a param optional without needing to supply a default value, they are not compatible with default values.

Nullable type expressions may also be used in type statements and in aggregate user-defined types. To avoid creating an artificial distinction between null values and omitted values, nullable types replace optional properties. Once this PR is merged, the following will no longer be valid Bicep:

type myObject = {
  property?: string
}

and would need to instead be expressed as

type myObject = {
  property: string?
}

This PR requires an update to the ARM runtime that has not finished rolling out (included in w02 release). The rollout has completed; this PR is no longer blocked.

Microsoft Reviewers: Open in CodeFlow

[jeskew]

I'm not sure if this is the right approach. All existing ARM constraints (except type) are no-ops if invoked on a value of null, but extensibility providers may have a need to block usage of an unforeseen decorator on nullable params or types.

The alternative is to update all the decorator definitions with assignability restrictions in SystemNamespaceType so that they accept nullable types (e.g., @minValue would need to be assignable to int | null instead of just int). This might make us more likely to accidentally block a future decorator's usage on nullable params, though, and is more verbose.

[anthony-c-martin]

It's a little quirky, but in the interest of not changing existing behavior, and with the fact that decorators are very infrequently added, I think it's OK - as long as you explain this well in a comment to avoid future surprises.

[anthony-c-martin]

As discussed offline, might be worth exploring an approach which utilizes the visitor state itself rather than an ad-hoc check using the syntax hierarchy.

[jeskew]

I couldn't find a reasonable way to implement this check in CyclicCheckVisitor without reimplementing some of the model's type manager, but the check can be made much simpler if it's performed after type checking has been performed. I added a second cyclic checker that runs as part of EmitLimitationCalculator.