não é possível converter/converter uma matriz de strings `string[]` em uma matriz de objetos `object[]`, mas posso fazer isso com todos os outros tipos no PowerShell

Com relação ao uso de@(...) , o operador de subexpressão de matriz , para criar uma [object[]]cópia do tipo _ de uma matriz:

• Seu código funciona como está no PowerShell (Core) 7 ; ou seja, @(...)produz de forma confiável uma [object[]]matriz do tipo , independentemente do tipo da matriz de entrada e independentemente de você usar uma conversão literal (por exemplo, [string[]]dentro de @(...))

• No Windows PowerShell (a edição legada, fornecida com o Windows, somente para Windows do PowerShell, cuja versão mais recente e atual é a 5.1), você precisa de uma solução alternativa ao usar uma conversão literal dentro de @(...), porque a v5.1 tem uma otimização mal aconselhada que otimiza o @(...)away neste caso (uma otimização que foi posteriormente revertida no PowerShell 7 ):

  • Usando @([string[]] (42, 43))como exemplo:

    • Conforme sugerido acima, simplesmente omitir a [string[]]conversão resultará em uma [object[]]matriz.

    • Se você precisar do elenco, use a seguinte solução alternativa:

      @([string[]] (42, 43) | Write-Output -NoEnumerate)

      • Envolver um cmdlet (que neste caso simplesmente passa cada entrada por ) desabilita a otimização e resulta na coleta usual da saída em uma [object[]]matriz.
      • Veja abaixo uma alternativa mais rápida.

• Sempre que @(...)funciona como pretendido, observe que, embora seja uma maneira conveniente de criar uma cópia[object[]] do tipo _ de uma determinada matriz, também é ineficiente :

  • Envolve enumerar o array, ou seja, processar seus elementos um por um e, então, coletá-los em um array (invariavelmente novo ), sempre do tipo [object[]]).

  • Veja a próxima seção para alternativas de melhor desempenho.

Com relação ao uso de restrições/casts do tipo array :

Observação:

• Uma restrição de tipo em uma variável (por exemplo, [object[]] $arrayO = ...difere de uma conversão (por exemplo, $arrayO = [object[]] ...) principalmente porque a primeira, em essência, reaplica implicitamente a conversão a futuras atribuições à mesma variável. ^[1]

• Estou me referindo e usando apenas conversões na discussão abaixo, mas o mesmo se aplica às restrições de tipo.

Daniel acertou em cheio em um comentário:

Surpreendentemente, o PowerShell - em ambas as edições - varia seu comportamento de conversão com base em se o tipo de matriz de entrada é (com base em) um tipo de valor .NET vs. um tipo de referência .NET . Os tipos de valor são os vários tipos numéricos[int] , por exemplo , , bem como tipos como [bool]e [char]que (invariavelmente diretamente ) derivam da System.ValueTypeclasse base abstrata: ^[2]

• A conversão de uma matriz baseada em tipo de valor .NET para qualquer outro tipo - incluindo [object[]]- resulta em uma matriz do tipo especificado (que é necessariamente uma cópia (de tipo modificado) da matriz de entrada).

• Converter um array baseado em tipo de referência[object[]] .NET para .NET é efetivamente uma operação sem efeito .

  • De forma mais geral , a lógica é: se o tipo de conversão for um tipo base (direto ou indireto) do array de entrada, a conversão é efetivamente uma operação nula , o que significa que o array de entrada é passado por .

    • Como [object]( System.Object) é a raiz da hierarquia de tipos .NET, segue-se que uma [object[]]conversão não é uma operação com qualquer matriz baseada em tipo de referência .NET; para ilustrar que o mesmo se aplica às classes base em geral:

      class Foo {} # sample class
      class Foo2: Foo {} # sample class that derives from [Foo]
      
      # Create a [Foo2]-based array
      $fooArray = [Foo2[]]::new(2)
      
      # Casting to [Foo[]] is a *no-op*, because [Foo2] derives from [Foo]
      ([Foo[]] $fooArray).GetType().ToString() # -> !! 'Foo2[]'
      

    • Entretanto, observe que isso implica que o tratamento especial de matrizes baseadas em tipos de valor .NET é, em última análise, arbitrário , dado que os tipos de valor também derivam, em última análise, de [object].

Soluções alternativas para garantir que uma matriz de um tipo especificado seja construída:

Se o desempenho for primordial , use a seguinte [Array]abordagem baseada em:

$arrayString = [string[]] ('foo', 'bar')

# Allocate an empty array of the desired target type.
$arrayObject = [object[]]::new($arrayString.Length)

# Copy the input array to the target array.
[Array]::Copy($arrayString, $arrayObject, $arrayString.Length)

A abordagem acima é de longe a de melhor desempenho, mas é prolixa e não óbvia.

A próxima opção mais rápida - e muito mais lenta - é usar uma foreachinstrução combinada com uma restrição de tipo:

[object[]] $arrayObject = foreach ($el in $arrayString) { $el }

A abordagem conceitualmente mais direta - embora ainda mais lenta que a foreachabordagem anterior - é usar uma sobrecarga específica do método intrínseco.ForEach() , que permite que você passe um literal de tipo para converter cada objeto de entrada; por exemplo:

$arrayObject = 
  ([string[]] 'foo', 'bar').ForEach([object])

Note que o acima não produz um [object[]] array , mas uma instância do tipo [System.Collections.ObjectModel.Collection`1[object]], que, no entanto, em termos práticos, se comporta como um array .
Se você precisa de um [object[]]array, especificamente, você pode simplesmente incluir o acima em @(...), o que, no entanto, envolve enumerar a coleção e então coletar os objetos enumerados em um array, o que aumenta a ineficiência.

A opção mais lenta de longe é a solução alternativa mencionada na seção superior:

[object[]] $arrayObject =
  $arrayString | Write-Output -NoEnumerate

^{[1] Há uma exceção curiosa: $b = [bool] 'foo'e [bool] $b = 'foo'não se comportam da mesma forma em sua atribuição (inicial); esta última causa um erro , porque a lógica de vinculação de parâmetros é aplicada inesperadamente: veja o problema do GitHub #10426 .}

^{[2] Para um determinado tipo, você pode facilmente determinar se é um tipo de valor .NET ou um tipo de referência .NET acessando a .IsValueTypepropriedade do tipo; por exemplo , [int].IsValueTypeis $true, enquanto [string].IsValueTypeis $false
No entanto, observe que as matrizes são sempre tipos de referência .NET ; por exemplo, [int[]].IsValueTypeis $false.
O C# fornece a structpalavra-chave para criar tipos de valor; o PowerShell não oferece uma maneira geral de criá-los (a classpalavra-chave cria tipos de referência , embora uma enumdefinição, especificamente, seja um tipo de valor).}