Suggestion - provide standard constraint sets or types for parameters

[NeilMacMullen]

I just decompiled a standard "website" ARM template and was rewarded with this code....

@minLength(1)
param hostingPlanName string

@allowed([
  'F1'
  'D1'
  'B1'
  'B2'
  'B3'
  'S1'
  'S2'
  'S3'
  'P1'
  'P2'
  'P3'
  'P4'
])
@description('Describes plan\'s pricing tier and capacity. Check details at https://azure.microsoft.com/en-us/pricing/details/app-service/')
param skuName string = 'F1'

I understand that the decompiler is just mechanically ripping this out of the ARM json but wouldn't it be a lot terser and human-friendly to be able to generate something like

@paramType AzureName
param hostingPlanName string

@paramType AzureWebSku
param skuName string = 'F1'

where AzureName and AzureWebSku are simply predefined in the tooling (and sourced from the actual Azure constraint schema).

[alex-frankel]

I'm pretty sure we have another issue for this, but I can't find it. We definitely want to do this and combine it with what we have planned for #622

Something like:

param skuName Web.Sites.Sku

Name is a little more complex as each resource type may have different naming requirements. So it is not possible to have a generic AzureName type, we could have something like Web.Sites.Name

@rynowak also has an interesting proposal in #1602 that would not require the parameter to be explicitly declared and we would have all they type info we need because we have the context for where it will be used.

[NeilMacMullen]

I like your syntax better than mine :-) I wasn't particularly hung up on AzureName - I'm painfully aware there are different conventions for different resources so you're dotted notation looks very nice. Of course, it's tempting to then think of this as a "type" and to prevent an Blob.Container.Name being passed to a Web resource but perhaps that kind of constraint checking is more easily done at run-time. In fact, given the amount of string-mangling done in the typical resource file, it might make more sense to go with the approach in #1602 and simply apply constraints to the final values being applied to properties rather than the input values of params.