11

I want to create an array containing arrays of two numbers. Pretty straightforward. However, If I do not provide a leading comma before the first array, it is incorrect. Why is this leading comma required?

PS C:\src\powershell> Get-Content .\fr-btest.ps1
$files1 = @(
@(4, 1024)
, @((7), (16))
)

$files1
$files1.GetType()
$files1.Length
$files1.Count
'========'

$files2 = @(
, @(4, 1024)
, @((7), (16))
)

$files2
$files2.GetType()
$files2.Length
$files2.Count

PS C:\src\powershell> .\fr-btest.ps1
4
1024
7
16

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     Object[]                                 System.Array
3
3
========
4
1024
7
16
True     True     Object[]                                 System.Array
2
2
lit
  • 14,456
  • 10
  • 65
  • 119

3 Answers3

17

@() is the array subexpression operator, which works differently than array construction operators you may be used to from other languages. The operator evaluates the nested subexpression and returns the output of that expression as an array. Meaning you can do something like this:

@(
Write-Output 'foo'
Get-Content 'C:\some\file.txt'
Test-Connection '192.168.23.42' -Count 1
)

and have an array come out.

For your first example this means that the two statements @(4, 1024) and , @((7), (16)) are evaluated individually, and the collective output of the two statements is then returned as an array.

The first statement (@(4, 1024)) outputs two integers, but the second statement (, @((7), (16))) outputs an array of two integers. That is because the leading comma in that statement is interpreted as the unary array construction operator (or comma operator), so you get an array nested in another array, and only the outer array is unrolled during output.

Essentially, your expression is the same as

$files1 = @(
4
1024
, @(7, 16)
)

or

$files1 = 4, 1024, @(7, 16)

Your second example avoids this pitfall, because both nested arrays are prepended with the unary array construction operator and thus protected from being completely unrolled.

With that said, I would recommend to define arrays in a more clear-cut way, e.g. like this:

$files1 = @(4, 1024),
          @(7, 16)

or (using grouping expressions instead of array subexpressions) like this:

$files1 = (4, 1024),
          (7, 16)

to avoid surprises like the one you observed. The outer @() isn't necessary for defining an array here. PowerShell automatically detects that via the trailing comma at the end of the first line.

For further information see about_Operators.

Ansgar Wiechers
  • 193,178
  • 25
  • 254
  • 328
  • 4
    Good answer, but I suggest not (also) calling `@(...)` an _array construction operator_; if you want to call it by another name, call it _array guarantor operator_; that is, loosely speaking, if something isn't already an array, make it one. To drive the point home that `@(...)` is _never_ needed to create array _literals_, I suggest removing the `@` from the final code snippet: `$files1 = (4, 1024), (7, 16)`. – mklement0 Dec 22 '18 at 22:27
5

The key to understanding the Array subexpression operator @( ) is the realization that you don't need it to create arrays, instead arrays are created with the Comma operator ,

As a binary operator, the comma creates an array. As a unary operator, the comma creates an array with one member. Place the comma before the member.

$myArray = 1,2,3
$SingleArray = ,1
$xs = (1,2,3), (4,5,6)       # Count: 2    
$ys = (1,2,3),
(4,5,6)                      # Count: 2

Now consider

# A - two expressions, each expression yields one array of size 3
(1,2,3)
(4,5,6)

# B - one expression resulting in an array of two elements
(1,2,3),
(4,5,6)

# C - similar to A except the sizes are 3 and 1 
#     (the second array contains a single element)
(1,2,3)
,(4,5,6)

And the final step is to realize that

in essence, the @(...) operation is syntactic sugar for [array] $(...)

as explained by the PowerShell Team Blog (The link was given by Christopher G. Lewis answer). Although the meaning and limitations of in essence is not entirely clear to me.

Micha Wiedenmann
  • 19,979
  • 21
  • 92
  • 137
  • *`@(...)` is just a syntactic sugar for `[array] $(...)`* That is plain wrong. Case 1: `$a = @($null); $b = [array] $($null); ConvertTo-Json $a; ConvertTo-Json $b`. Case 2: `$a = @(,[array]0); $b = [array] $(,[array]0); ConvertTo-Json $a; ConvertTo-Json $b`. – user4003407 Dec 22 '18 at 22:39
  • You seem to know more about this, would you mind editing the answer and fixing it? Especially since the claim is made in the PowerShell Team Blog. – Micha Wiedenmann Jan 03 '19 at 13:47
  • Well, except that last claim, answer is correct. You absolutely do not need `@(…)`, when you use `,` as array construction operator. – user4003407 Jan 04 '19 at 12:30
  • 1
    What is your opinion on the explanation given by the PowerShell Team Blog? – Micha Wiedenmann Jan 04 '19 at 12:34
3

Powershell uses both a comma and a line break as an array separator. Your first declare:

$files1 = @(
@(4, 1024)
, @((7), (16))
)

Creates the following:

$files1[0] = 4
$files1[1] = 1024
$files1[2] = @(7,16)

Your second declare

$files1 = @(
, @(4, 1024)
, @((7), (16))
)

Creates the following:

$files1[0] = @(4, 1024)
$files1[1] = @(7, 16)

As to the parsing decision, it is dependent on the first non-white space character encountered on a line: Array Literals In PowerShell and Understanding PowerShell Parsing Modes

mklement0
  • 382,024
  • 64
  • 607
  • 775
Christopher G. Lewis
  • 4,777
  • 1
  • 27
  • 46
  • _PowerShell uses both a comma and a line break as an array separator_ is not quite correct: PowerShell has no array _separator_; `,` is the array _construction_ operator. Inside array-subexpression operator `@(...)` - the content of which is not an _array_ - it is _statements_ that you can separate with line breaks (in lieu of `;`). – mklement0 Dec 22 '18 at 22:37