Support numeric types other than 32bit integers

[onionhammer]

Bicep version
v0.1.37-alpha

Describe the bug
When I try to add a parameter that takes a large input ,like the following, i receive an error
Error BCP010: Expected a valid 32-bit signed integer

param sqlMaxSize int {
    default: 2147483648
}

However, 'maxSizeBytes' of Microsft.Sql/servers/databases allows larger than 32-bit int

[alex-frankel]

does this work if you were to adjust the defaultValue in the ARM template JSON? I think that is (supposed to be) the max size for a parameter of type int, but it is possible that SQL accepts that.

[anthony-c-martin]

FWIW the JSON spec doesn't define a maximum number size. NewtonSoft.Json (the library used by ARM and many RPs to process JSON) allows numbers up to 380 digits long; we should probably update Bicep to align:

https://github.com/JamesNK/Newtonsoft.Json/blob/666d9760719e5ec5b2a50046f7dbd6a1267c01c6/Src/Newtonsoft.Json/JsonTextReader.cs#L60-L62

https://dotnetfiddle.net/iPcWhP

[anthony-c-martin]

There's also the question of supporting other number formats like floats, decimals and binary/hex notations

[alex-frankel]

@majastrz - do you know why we set the current limit on our int type?

[majastrz]

This is a really good issue! Totally agree we should align with Newtonsoft for literal values, but need to confirm that the runtime handles them correctly.

[slavizh]

Probably it is not related to that but certain ARM Template functions (like mul()) have limit on the maximum number supported. Was not very high limit but I do not remember how much. It can be easily tested though.

[anthony-c-martin]

Probably it is not related to that but certain ARM Template functions (like mul()) have limit on the maximum number supported. Was not very high limit but I do not remember how much. It can be easily tested though.

Thanks for pointing this out. That's definitely something we'll need to be careful with.

[anthony-c-martin]

FY I've updated the title to cover other numeric types

[majastrz]

In the runtime we have two types: int and number. The latter covers floating point numbers and big integers. Some of the functions can use ints and some use number types. (I left TODOs in bicep on functions that support the number type.) The runtime allows number in literal values and maybe also in param/var values (the latter part needs to be verified).

I think the bare minimum we can do is match the runtime behavior in bicep. Ideally, I would like to remove the distinction between int and number from the runtime entirely but I don't know how feasible that would be. I don't think we should be adding more number types to bicep, though.

[alex-frankel]

To unblock, you can use a string parameter type which this resource type should accept (quickstart example). We'd like to do a short-term fix to allow you to use the int type with these large values, and then do a more proper fix that @majastrz detailed above.