Support separating array and object items with a comma instead of a newline

[Stijnc]

In a lot of languages array items are separated by a comma.
It feels weird to not use comma's for array items.

Current

param sku string {
    default: 'Basic'
    allowed: [
        'Basic'
        'Standard'
        'Premium'
    ] 
}

Proposal
Allow the array items to be split using a comma as it feels more natural.

param sku string {
    default: 'Basic'
    allowed: [
        'Basic',
        'Standard',
        'Premium',
    ] 
}

[alex-frankel]

It's on our short-list to support comma-separated values for arrays and object, but our plan is to make them optional. This will allow for the above as well as single line arrays:
var simpleArray = [1, 2, 3]

Any concerns with commas being optional and users having the choice here?

[alex-frankel]

(also I'm going to co-opt and rename the issue if that's ok. I thought we already had an issue tracking this)

[alex-frankel]

Internally, we are going back and forth on:

1. should we allow commas at all? In other words, keep what we have and single line arrays/objects would not be supported
2. allowing comma, but making them optional. YAML does this, but from what we can gather there are not many other languages that do this.
3. requiring commas and no longer allowing items to be separated by a newline. This is more common in general purpose programming languages.

It would be great to get feedback on which of the above options is most desirable.

[Stijnc]

Personally I would opt for number 3.
It aligns with most programming languages.
Number 2 will only drive best practice discussions.

Whatever the choice, please no 2 ;-)

[jhueppauff]

I agree, 3 is the most logical options (at least for .net developer :D)
Especially if I think about array of objects I think the best will be commas.

[OxHobbs]

A vote for number 3 with also allowing a trailing comma for cleaner source control updates in the future. Again mimicking what other general purpose languages allow.

param location string {
  allowed: [
    'eastus',
    'eastus2',
  ]
}

param location string {
   allowed: ['eastus', 'eastus2', ]
}

[slavizh]

Somehow I prefer the current option where commas are not needed when you use new lines but are needed when you use the array in one line. It will be also for me initially hard to get used to this but it looks cleaner. Second preference is commas and allow both one liner and multiple lines.

[SimonWahlin]

I vote for 3, but please allow for trailing comma (great idea @OxHobbs ).

Adding/removing commas after reordering lines in an array is a hassle.

[anthony-c-martin]

My thoughts:

1. We should always try and avoid providing 'optional' syntax with different ways of doing the same thing, because it'll make docs and examples diversified and more complicated to understand for beginners (with the exception of a trailing comma; it's a common pattern and has genuine utility for source control).
2. Syntax for multi-line and single-line declarations for arrays should not be vastly different, otherwise conversion between each will be confusing.
3. Points (1) and (2) lead me to either "always commas" or "never commas".
4. The two benefits (IMO) that commas provide in a single line declaration are:
   1. Visual separator to make reading and understanding the code simpler.
   2. Allow the compiler to do a better job of error recovery when parsing a partially (or incorrectly) typed document.
5. I definitely like how clean the syntax is to read today without commas, and am not 100% sold on "if we want a single-line array declaration, we must reintroduce commas". I feel like we need a better understanding of the drawbacks in point (4) to make this decision.

[bmoore-msft]

if you want a single line array declaration without commas, the member types must be simple types (string, int, bool).

If you want complex type members, use multi-line and commas.

Though personally I don't like 2 different syntaxes for arrays. That just adds confusion, IMO.

[shenglol]

I'm with @anthony-c-martin on the "always commas" or "never commas" bullet, and I also don't think we must reintroduce commas in a single-line array declaration - there are a number of functional programming languages like Lisp and Racket that don't use commas in an array declaration. For me the following statements are equally readable (it's just a matter of getting use to it):

var greetings = ["Hello" "Hola" "Bonjour"]
var greetings = ["Hello", "Hola", "Bonjour", ]

Personally I have no preference, but if we go with the "always commas" option, we would need to consider whether to make the trailing comma required or not.

[alex-frankel]

+1 on the sentiment of "always or never, but not both". Personally, I am a fan of commas because at that point it is a javascript object literal and there are tools for translating between JSON and javascript objects: https://json-to-js.com/. That would be convenient when converting template code or working directly with the Azure API (i.e. the new "View resource JSON" functionality in the Azure portal)

we would need to consider whether to make the trailing comma required or not.

@shenglol, what is the reasoning behind requiring the trailing comma?

[majastrz]

+1 on "always or never" as well. @alex-frankel I think long-term we should have "Export/View as Bicep" blades in the portal which should help with your concern.

If there are commas, then in my opinion the trailing comma should be optional.

I think @shenglol just moved me to team "no comma" 🙂. (I didn't know that there are somewhat popular languages that don't have a separator between array items.)

[shenglol]

@shenglol, what is the reasoning behind requiring the trailing comma?

Having trailing commas is helpful in that it:

1. produces much cleaner diff results.
2. makes code manipulation easier, e.g. switching two lines.

To revise what I said, maybe we should relax and make dangling commas optional because typing them can sometimes be annoying, but once we implement a code formatter for bicep, we can add an option to always let the formatter insert them (which is a common configurable thing in modern code formatters like Prettier and Black).

[benc-uk]

I really like how clean the code looks without the commas. I'd much prefer commas to only be required when using a single line e.g. [ "foo", "bar" ]
Which AFAIK is exactly how YAML operates https://yaml.org/spec/1.2/spec.html#id2759963

I think the comma at the end of new lines puts Bicep one step closer to looking like JSON, i.e. a step backwards

[ChristopherGLewis]

As someone who does automation extensively, in ARM, Ansible, and Terraform, I'm going to ask you to consider that you use some format that uses a standard language/DDL.

ARM is JSON, Bicep is JSON-ISH. I would love it if objects in Bicep were valid JSON objects and that would mean arrays being a JSON Arrays,

I've been coding in bicep extensively for about 3 weeks, and I can see using some sort json to bicep converter. Even if its something simple like generating a list of valid regions, I'd prefer cutting and pasting this:

(Get-AzLocation | Where-Object { $_.location -like "*us" -or $_.location -like "*us2"}).location
[
    "centralus",
    "eastus",
    "eastus2",
    "westus",
    "northcentralus",
    "southcentralus",
    "westcentralus",
    "westus2"
]

[riezebosch]

I'm currently watching the video from Ignite and my first response is: why not make it look more like YAML in general?? I don't get the need for curly braces as well.

var websites = [
  {
    name: 'fancy'
    tag: 'latest'
  }
  {
    name: 'plain'
    tag: 'plain-text'
  }
]

Something along the lines:

var websites =
- name: 'fancy'
  tag: 'latest'
- name: 'plain'
  tag: 'plain-text'

Source of @alex-frankel demo : https://github.com/alex-frankel/ignite-spring-21/blob/6a8015d88d1d29a13617e2fa66b06ac206d8df01/main.bicep#L16-L25

[miqm]

Adding my opinion to the discussion : I'm with always or never plus no comma team:)

Copy paste from json to bicep will not work as we use single quotes instead double quotes.

Commas are redundant here IMHO.

[duncanmak]

What if you add "," as one of the possible whitespace literals?

Some might complain that this would along ['foo' 'bar' 'baz'] but unless they come from the LISP world, most people will just write it with commas.

This is the choice that Clojure made in their surface syntax - see https://github.com/edn-format/edn