Use resource types for parameter validation

[jeskew]

Is your feature request related to a problem? Please describe.
With the user-defined types preview enabled, users can declare custom types and validate that parameters match those type declarations. If a parameter value is passed directly to a resource as a property, however, users need to re-declare the existing type definition as type symbols within their template (or forgo validation).

Describe the solution you'd like
It should be possible to use an existing resource type (or portion thereof) from a built-in or imported namespace. This could be accomplished via typeof function or keyword, such as in typeof('Microsoft.KeyVault/vaults@2022-07-01#properties.accessPolicies[*]').

If we want to leave room for a similar function that gets the assigned type of a variable or parameter, we might need two functions or to require the resource keyword:

param foo { bar: string }
param bar typeof(foo).bar
param accessPolicy typeof(resource 'Microsoft.KeyVault/vaults@2022-07-01').properties.accessPolicies[*]

[jeskew]

One thing to keep in mind with provider-supplied types is that the compiler doesn't trust that they are completely accurate (or that they will remain completely accurate during the period between when the template is compiled and when it is deployed). Type checking based on resource types will generate warnings accompanied by links to report type inaccuracies, while type checking based on something defined within the template itself will generate errors.

Consequently, typeof(resource ...) should not have the same representation in the compiled template that custom types explicitly defined by the template author do. Explicitly defined types are compiled into ARM constraints, violations of which cause the deployment to fail. One potential solution here would be to compile typeof(resource ...) derived types into a metadata entry. For example,

param accessPolicy = typeof(resource 'Microsoft.KeyVault/vaults@2022-07-01#/properties/accessPolicies/*')

might compile to:

{
  "parameters": {
    "accessPolicy": {
      "type": "object",
      "metadata": {
        "__bicep_resource_type": "Microsoft.KeyVault/vaults@2022-07-01#/properties/accessPolicies/*" 
      }
    }
  }
}

Some open questions with this approach:

1. What happens if a compiled template being consumed as a module refers to a type that is unknown to the parent template? For example, if the module is using an earlier version of Bicep.
2. It is possible for resource type definitions to diverge over time. Is it OK if a parent template and a module, compiled using different versions of Bicep, report incompatible types under the same identifier?

[richardissimo]

On first reading, this looks like it is simply a way of allowing people to declare a variable's type based on an existing type. For example, following the example in there, I can see that if it was in place, then rather than writing...

param serviceBusNamespaceName string

...then I could declare...

param serviceBusNamespaceName typeof(resource 'Microsoft.ServiceBus/namespaces@2022-01-01-preview').properties.name

So we've replaced the direct reference to a string type with an indirect reference to the same type.

However, I've been referred here from #9797 by @jeskew, with the implication that this has an additional behaviour, which I didn't "get" this from reading the proposal, so I wanted to check... @jeskew are you proposing that:

When declaring a parameter by using a reference to a property, the declaration is saying that not only the type of that property would come across to this declaration; but any validation decorators applied to that property would come too. So for example, if the Service Bus name property had 3 validation decorators (e.g. a regex validation, minimum and maximum string length), those would be applied to this parameter.

[alex-frankel]

Yes that's right. Can you clarify why you would not want that? IOW, what are you looking to enable with this typeof() parameter type if not to restrict the input to what that property allows?

[richardissimo]

Can you clarify why you would not want that?

I didn't say that I didn't want it, I was just surprised :) ... I've used plenty of languages over the years, and I don't recall seeing something like this before (a type declaration which includes specific validation logic); but that doesn't mean it isn't a good idea.

I'm guessing that it probably infers all of the decorators, because there is probably no way to distinguish the validator decorators from the others; and that's probably fine, too.

The derived declaration may want to override some of them, like @description: for example, there might be two parameters both of the same type, and you might want to distinguish between them.

There might need to be a way to prevent something coming across, although I'm not experienced enough with Bicep to give an example... perhaps the @metadata might apply to the original declaration, but not the derived declaration?

[iivmok]

To me and our large insurance company's usage even just a typehint to the language server would already help immensely. Currently all var objects are typeless basically, and telling the lang server something simple, that this is indeed a Microsoft.Web/sites@2022-09-01.properties (or partial of it) and not just a random object would be really helpful.

[jeskew]

Based on a team discussion, the initial implementation will use a slightly different syntax from the proposal described above. Instead of a typeof(resource ...) function, there will instead be a resource<...> utility type (syntax and name cribbed from TypeScript). E.g., instead of typeof(resource 'Microsoft.KeyVault/vaults@2022-07-01').properties.accessPolicies[*], the syntax would be resource<'Microsoft.KeyVault/vaults@2022-07-01'>.properties.accessPolicies[*].