Automatic type casting in output

[WhitWaldo]

Is your feature request related to a problem? Please describe.
ARM templates often have a mix of integer and number types sprinkled throughout. While it makes sense that a quantity should use an integer, sometimes properties that seem like they would be expressed as strings are actually supposed to be expressed as numbers.

Describe the solution you'd like
It'd be great if Bicep were aware of the expected types for each of the given properties and 1) automatically cast the value to the appropriate type in the output and 2) where that isn't possible, it then fails the build with a clear description of why it wasn't able to cast it (e.g. 'can't transform value with alphabetic characters to an integer'.

To some extent, this may be managed once Intellisense is added as it would presumably be aware that I put a string for a property expecting an integer, but to have logic that specifically cast it would open the door for more elaborate logic within Bicep (e.g. piece a number together by concatenating it as a series of strings, then Bicep automatically cast this string to an integer in the output).

[alex-frankel]

1. automatically cast the value to the appropriate type in the output and

Isn't this dangerous? Would TypeScript do this? I wouldn't think this would be a compile-time type error. If you have a type-error that is a false positive, you can wrap the value in an any() function to pass validation.

2. where that isn't possible, it then fails the build with a clear description of why it wasn't able to cast it (e.g. 'can't transform value with alphabetic characters to an integer'.

I believe we are doing this today with the bits in main. Would be great if you can try that out and let us know if that is what you are expecting to see w.r.t validation.

[WhitWaldo]

I posted this in frustration after finding that several dozen strings I'd written should instead be expressed as numbers across my load balancer objects. There was no warning in Bicep given and I only saw the warning when looking through the produced ARM file (thus the frustration).

Here's a sample you can repro with:

resource lbManagement 'Microsoft.Network/loadBalancers@2020-05-01' = {
    name: loadBalancerManagementName
    location: location
    dependsOn: [
        pipManagement
    ]
    properties: {
        probes: [
            {
                name: tcpProbeName
                properties: {
                    intervalInSeconds: '5'  //Should be expressed as an integer
                    numberOfProbes: '2'  //Should be expressed as an integer
                    port: ntFabricTcpGatewayPort
                    protocol: 'tcp'
                }
            }
//...

It yields the following (image included so you can see the warning squigglies):

Here's another case:

resource nsgCollection 'Microsoft.Network/networkSecurityGroups@2020-05-01' = {
    name: nsgCollectionName
    location: location
    properties: {
        securityRules: [
            {
                name: 'allowAppPortHttp'
                properties: {
                    access: 'Allow'
                    description: 'Allow application traffic via HTTP'
                    destinationAddressPrefix: '*'
                    destinationPortRange: 80 //Should be expressed as a string, not an integer
                    direction: 'Inbound'
                    priority: 500
                    protocol: '*'
                    sourceAddressPrefix: 'VirtualNetwork'
                    sourcePortRange: '*'   
                }
            }

But you're right - build-time type casting is fraught with danger and shouldn't happen.

That said, I'd be happy to keep on reporting cases where Bicep failed to warn on validation at build as that would solve the issue I experienced here. I don't know that I've ever seen an ARM validation issue at build, so perhaps those bits aren't yet live.