Compound assignment operators don't obey StrictMode in dynamic scope

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

Continued discussion from https://github.com/PowerShell/PowerShell/issues/17911

Compound assignment operators (e.g. +=, -=, *=) behave weirdly when operating on non-existent variables in dynamic scope, e.g. functions. This is even when using Set-StrictMode -Version 3.0 which does protect against most other undefined variable uses:

> Set-StrictMode -Version 3.0
> function Test-Increment { $x++; $x }
> Test-Increment
InvalidOperation: The variable '$x' cannot be retrieved because it has not been set.
InvalidOperation: The variable '$x' cannot be retrieved because it has not been set.

> function Test-Assign { $x = $x + 1; $x }
> Test-Assign
InvalidOperation: The variable '$x' cannot be retrieved because it has not been set.

> function Test-CompoundAssign { $x += 1; $x }
> Test-CompoundAssign
1

Do note that it only happens in dynamic scope, as in regular prompt all of those statements are caught:

> $x++; $x
InvalidOperation: The variable '$x' cannot be retrieved because it has not been set.
InvalidOperation: The variable '$x' cannot be retrieved because it has not been set.
dkaszews@Cuddles-Berry:~/Downloads

> $x = $x + 1; $x
InvalidOperation: The variable '$x' cannot be retrieved because it has not been set.
InvalidOperation: The variable '$x' cannot be retrieved because it has not been set.

> $x += 1; $x
InvalidOperation: The variable '$x' cannot be retrieved because it has not been set.
InvalidOperation: The variable '$x' cannot be retrieved because it has not been set.

Expected behavior

> function Test-CompoundAssign { $x += 1; $x }
> Test-CompoundAssign
InvalidOperation: The variable '$x' cannot be retrieved because it has not been set.

Actual behavior

> function Test-CompoundAssign { $x += 1; $x }
> Test-CompoundAssign
1

Error details

No response

Environment data

Name                           Value
----                           -----
PSVersion                      7.3.0-preview.3
PSEdition                      Core
GitCommitId                    7.3.0-preview.3-304-gd02c59addc24e13da3b8ee5e1a8e7aa27e00c745
OS                             Linux 5.15.0-1013-raspi #15-Ubuntu SMP PREEMPT Mon Aug 8 06:33:06 UTC 2022
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

No response

[SeeminglyScience]

Proposed solution is to create a new Set-StrictMode -Version 4.0 to avoid any breaking changes.

I do also want to note that this isn’t exactly the easy solution it seems to be off the bat. Every time a new version is added, it splinters into a new dialect which needs to be tested separately. It’s a high maintenance burden that needs significant value-add to be considered.

[daxian-dbw]

@dkaszews Sorry that I missed your last comment.

Here is a quick search of Set-StrictMode -Version latest in GitHub: https://grep.app/search?q=Set-StrictMode -Version latest. You can take a look and see how much it’s used.

I know the doc called out the caveat of using Latest, and yeah according to the behavior we defined in the doc, whoever uses latest opts into receiving stricter rules. But they will find stuff stop working when upgrading to a new PS version, so it’s still practically a breaking change.

I’m not saying any breaking change is a hard big NO. It will need closer look from the team to weigh the value and cost.