If-else blocks and array types

[SergeyTeplyakov]

PowerShell drives me nuts (I hope I missing something here).

Consider following code:

$var = $True

$foo = if ($var) {@(, 1)}

$foo # 1
$foo.GetType().FullName #System.Int32

$foo = @(, 1)

$foo # 1
$foo.GetTYpe().FullName #System.Object[]

Clearly that behavior should be the same. Right? But not exactly. Here is an output:

1
System.Int32
1
System.Object[]

I would say that this is a bug, not a trap!

[nightroman]

Yes, so far it looks like a bug to me. I cannot find an explanation. Well, some bugs are traps, too. Perhaps this should be in the list.

[SergeyTeplyakov]

I would like to see them in this list. As long as they're exists in the language. When they'll gone, trap could be renamed or marked as a deprecated.

[nightroman]

No, it looks like not a bug but yet another example of "unrolling", see Unrolled-collections.

Modified example:

    $list = [System.Collections.ArrayList](1, 2)

    # System.Object[]
    $foo = if (1) {$list}
    $foo.GetType().FullName

    # System.Collections.ArrayList
    $foo = $list
    $foo.GetType().FullName

It's definitely a trap. I was fooled again for the moment. I will add this example to the case. It shows that unrolling works even in such simple cases.

[nightroman]

And even simpler case perhaps

# System.Object[]
$foo = $($list)
$foo.GetType().FullName

# System.Collections.ArrayList
$foo = $list
$foo.GetType().FullName

[SergeyTeplyakov]

The question is: why if statements unrolls a collection? It is make no sense to me. For me (and, I assume for most other developers) if statement (if pseudo-expression in this case) should have no side effects like this.

[SergeyTeplyakov]

Thanks a lot! Last example shed some light on the PowerShell behavior!

Ok. Now I can't tell that this is a bug, but it even worse! It is by design!

[nightroman]

The question is: why if statements unrolls a collection?

Because with if it works as a block of statements (0, 1, 2, or more). The case of 1 statement is included, unrolling works anyway.

[SergeyTeplyakov]

Because with if it works as a block of statements (0, 1, 2, or more). The case of 1 statement is included, unrolling works anyway.

Make sense.

[nightroman]

And this is yet another reason why it's not good that a ternary operator is missing in PowerShell. if/else does not exactly replace it, as we can see.

[SergeyTeplyakov]

+1. And pseudo-expression nature of the language add fuel to the fire.

[nightroman]

Here it is on Connect: Add ternary (? :) operator to script language. I added a comment there.

[nightroman]

The true workaround for a ternary operation may look like this

@($var1, $var2)[!$condition]

[nightroman]

• Added Test-4-unrolled-if.ps1 to Unrolled-collections.
• Added a new case Missing-ternary-operator which is different but overlaps.