JOjodrellblank·Jan 20, 2021
Potentially, if someone adds a new parameter which clashes so the prefix you used is not unique. PowerShell 7.x is introducing support for traditional C-style ternary expression "a ? b : c" and there's a potential syntax clash there because PowerShell has always allowed variable names to end in a question mark, e.g. "$isConfigured?" and with that there's no way to stop "$isConfigured? a : b" parsing as a variable name and then an error. The official way forward is to mandate that variable names used with ternary expressions must use the full-brace names like ${isConfigured?}, which is annoying.
People don't want that, but the PowerShell Team are not moving easily to a possible-break of backwards compatibility in how the language parses variable names. It's been discussed here: https://github.com/PowerShell/PowerShell/issues/3240 for doze
Read the rest
ns of comments, and goes:
"@PowerShell/powershell-committee reviewed this one today, we have a couple thoughts: No matter what we do, we're going to do some analysis of our corpus of scripts to see how often folks use ? in variable names. Some of us have a hypothesis (that others would like to validate) that the users who are using ? in their variable names may be less advanced users (as we agree in this room we'd stay away from it because of the potential problems that could arise). On the other hand, anyone using the functionality described here will be able to understand a slightly more complicated syntax (like ${foo}?.bar). Therefore, we prefer option 3 because it avoids breaking changes on these less experienced users."
The committee ruled to keep the need for ${}, then the ternary expression became a gated experimental feature in PowerShell 7, you have to opt-in to enable it. One of the PowerShell developers analysed the PowerShell Corpus of 400k+ scripts collected by Lee Holmes and Daniel Bohannon for security threat research[2][3] and said "I found that about 62% of variables that have ? in them use it in the end. That made me lean towards not introducing a breaking change." - in the comments on a pull request[4]. Then someone else made another analysis of the corpus with regex and came up with 329 out of 22,000,000 of variables have a potentially clashing "?" at the end.
It's been reopened as another discussion[5] and another person came up with an analysis of the Corpus with proper tokenising/parsing[6] and came up with 11 variables ending in ? out of 1,896,983 unique variables used[6] which then narrowed down to 1 that might break in backwards compatibility if this change happens. Coming up 4 years of back and forth discussion, even with that kind of evidential backing, with 2 core developers, the Team Lead and Bruce Payette one of the original developers weighing in against, being brought up in a community call, then flagged for review by the committee, then reopened as a reminder again[7] the team is still not won over on the risk of breaking backward compatibility by changing ? parsing at the end of a variable name.
That is, yes "possible not forward compatible for future parameter addition", especially by third party modules who might not take it as seriously, but not at all casually by PowerShell's developers.
[2] https://www.fireeye.com/blog/threat-research/2017/07/revoke-...
[3] https://aka.ms/PowerShellCorpus (1.2GB compressed)
[4] https://github.com/PowerShell/PowerShell-RFC/pull/223#discus...
[5] https://github.com/PowerShell/PowerShell/issues/11379
[6] https://github.com/PowerShell/PowerShell/issues/11379#issuec...
[7] https://github.com/PowerShell/PowerShell/issues/14025