René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"@() (array-subexpression operator) should not be optimized away when a cast to an array type is involved","articleBody":"\u003csup\u003eThis is a follow-up to the discussion involving @daxian-dbw and @PetSerAl in #4257\u003c/sup\u003e\r\n\r\nContext:\r\n\r\n* PSv5.1 introduced a generally helpful optimization that optimizes `@()` away in cases where an array is _directly_ constructed inside of it.\r\n   * I presume that the motivation for this optimization was the widespread, but redundant and inefficient practice of enclosing `,`-constructed arrays (\"array literals\") in `@()`, such as in `@(1, 2)`, where `1, 2` would not only suffice, but, in PSv5-, `@()` would actually (effectively) _clone_ the array.\r\n\r\n* **Unfortunately, this optimization is also applied when a _cast_ to an array type (e.g, `[int[]]`) is involved, which can have unpleasant side effects** - see below.  \r\n_Not_ optimizing in this scenario makes for conceptually clearer, predictable behavior.\r\n\r\n* While a change would technically be a breaking one, it is hard to imagine anyone having relied on the optimized behavior _with casts_ - a typical [Bucket 3: Unlikely Grey Area](https://github.com/PowerShell/PowerShell/blob/master/docs/dev-process/breaking-change-contract.md#bucket-3-unlikely-grey-area) change.\r\n\r\n   * Also note that when the optimization was _introduced_ in PSv5.1, it was technically a breaking change too - though I suspect it wasn't announced as such or even at all.\r\n\r\nSteps to reproduce\r\n------------------\r\n\r\n```powershell\r\n@([int[]] (1, 2)).GetType().Name\r\n\r\n$arr = 1, 2; @([int[]] $arr).GetType().Name\r\n```\r\n\r\nExpected behavior\r\n-----------------\r\n\r\n```none\r\nObject[]\r\nObject[]\r\n```\r\n\r\nActual behavior\r\n---------------\r\n\r\n```none\r\nInt32[]\r\nInt32[]\r\n```\r\n\r\nNote that versions up to and including v5 - before the optimization was introduced - behave as expected.\r\n\r\nWhy is the current behavior problematic?\r\n-----------------------------------------\r\n\r\n\u003csup\u003eThe examples in this section are courtesy of @PetSerAl.\u003c/sup\u003e\r\n\r\nAll examples are undoubtedly edge cases, but the larger point is that this behavior should never have been introduced, and, given its \"stealth status\", this is an opportunity to get rid of it.\r\n\r\n* It subverts the fundamental assumption that `@()` always creates regular PowerShell arrays (`System.Object[]`):\r\n\r\n```powershell\r\n\u003e @([int[]] (1, 2))[-1] = 'foo'   # BREAKS, because the array is [int[]], not [object[]]\r\nCannot convert value \"foo\" to type \"System.Int32\".  ...\r\n...\r\n```\r\n\r\n@PetSerAl points out that this fundamental assumption is even still reflected in other places in the source code: [`ArrayExpressionAst.StaticType`](https://github.com/PowerShell/PowerShell/blob/master@%7B2017-07-18%7D/src/System.Management.Automation/engine/parser/ast.cs#L9490) (a `@(...)` expression is of type `[System.Management.Automation.Language.ArrayExpressionAst]`).\r\n\r\n* It subverts the expectation that `@()` always _clones_ an array:\r\n\r\n```powershell\r\n\u003e $a = [int[]] (1, 2); $b = @([int[]] $a); [object]::ReferenceEquals($a, $b)\r\nTrue    # $a and $b unexpectedly reference the same array.\r\n```\r\n\r\nNote that the accidental reference equality only happens ~if the source type and the cast type are identical~ if the cast type is either the same as the source type or a type that the source type is (directly or indirectly) derived from (covariance).\r\n\r\nThus, if the _cast_ type is `[object[]]` and the source type is a reference type too, the problem always surfaces.\r\n\r\nEnvironment data\r\n----------------\r\n\r\n```powershell\r\nPowerShell Core v6.0.0-beta.4 on macOS 10.12.5\r\nPowerShell Core v6.0.0-beta.4 on Ubuntu 16.04.2 LTS\r\nPowerShell Core v6.0.0-beta.4 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)\r\nWindows PowerShell v5.1.15063.413 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)\r\n```\r\n","author":{"url":"https://github.com/mklement0","@type":"Person","name":"mklement0"},"datePublished":"2017-07-18T14:27:02.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":31},"url":"https://github.com/4280/PowerShell/issues/4280"}