Powershell: null条件のメンバーアクセスのために変数名の周りに{...}を必要としない

明確にするために、マイルストーンは、チームがフィードバックに基づいて話し合うべきものであることを意味するだけであり、この変更を行うことを約束しているわけではありません。

@ mklement0

？ {...}で囲まずに、識別子の一部として許可されるべきではありませんでした。

うーん-PowerShellの最初の基本言語は$を使用するPosixシェルでしたか？ 終了コードqed '？' 引用符で囲まれていない変数名で許可されます。

（意味のある）古いバージョンでは実行できません

確かにそれはできます：

PS>  $abc?=@{a=1; b=2; c=3}
PS>  $abc?.b                                                                                        1
PS>  2                      

確かにそれはできます：

_新しいセマンティクスで_（null条件付きアクセス）意味のある実行はできません-それが私が言うつもりのすべてです。

はい、あなたの例は現在機能していますが、_異なるセマンティクスで_（ abc? ? _変数名と見なされる?.は期待どおりに機能します。

PowerShellの最初の基本言語は、終了コードに$?を使用するPosixシェル

$?は、POSIXのようなシェルの_例外_です。 次のことはできません。

# bash, ksh, zsh, dash (all common /bin/sh implementations)
foo?='bar' # BOOM! E.g. "bash: foo?=bar: command not found"

（そして、明らかに、PowerShellで$?を廃止するように求める人は誰もいません。）

そして、当然のことながら、 $?と同じスペースにある_他のすべての_自動変数（つまり、 $^と$$ ）は明示的に特別です-トークナイザーでケースに入れられます。 そして、実際のところ、（現在）必要はありませんが、 $?もそうです。

コードが書かれた時点で、 ?は有効な識別子文字ではないと予想されていたのは明らかだと思います。

スクリプトの変数名の最後に?を使用した人は1人しか知りません。それは、@ StartAutomatingです。 彼は実際にその構文を使用しているので、この議論に注意を向ける価値があると思いました。

また、 @ vexx32 、 $?がトークナイザーで特殊なケースになっている理由は、 ?で始まる名前の変数を作成できないためです。 たとえば、 $??? = 'foo'は解析されません。 変数名は英数字またはアンダースコアで始まる必要があり、現在は英数字、アンダースコア、または疑問符を含めることができます。 ?.をnull条件のメンバーアクセス演算子として解析する必要があることに同意しますが、 ?がトークナイザーで特殊なケースになっている理由を明確にしたいと思いました。

このチャットに注意を向けてくれてありがとう。

その価値について、私はいくつかの考えを持っています：

1. これらの変数はまれですが、バックコンパットがスクリプトを壊したときにモグラたたきをしたいと思う人は誰もいません。
2. 非常にオタクな人は別として、$ {obj}？。Method（）または$ obj？.Method（）は少し上昇すると思います。 そこにヌルを管理する方法についての10年間のガイダンスがウェブ上にあります、そして私は多くの人々がif（$ obj）{$ obj.Method（）} _ v7バンドワゴンに乗るためだけに切り替えるのを見ません_
3. さらに、予期しない変数名に問題があるほとんどの人は、$ {}構文を学習します（すでにアンダースコアで自然にヒットしています）。 「この機能を使用したい人」と「$ {}構文をすでに知っている人」のベン図の重複はほぼ100％になると思います。
4. 上記の構文は完全な部分式ほど強力ではなく、完全な部分式はコアでも機能しないので、ほとんどの人がこれを今後も使用し続けると思います。

したがって、数学を実行すると、これを実行しない具体的な理由がいくつかあり、これを実行する理由は1つだけです（一部のユーザーにとっては、より簡単な場合があります）。 の有病率が低いことを考えると？ 変数名では、あなたはあなたが害するよりも多くの人々を助けるかもしれませんが、私の意見ではそれはコイントスです。

そのようなコイントスの利益の可能性を考えて、私はロバート・マクナマラを言い換えます。

$obj?.Method() <var i="9">Method</var>()がデフォルトで$<var i="6">obj</var> ?. <var i="9">Method</var>()し、 $<var i="11">obj?</var> .のみフォールバックするようにすることをお勧めします<var i="14">Method</var>() 、 $objがスコープに存在しないが、 $obj?は存在し、 #requires ‑Versionはv7 +ではない場合。

@ ExE-ボス、それはこの特定のルールのために作る多くの例外のようです。

この特定のルールの価値についての質問を繰り返します。

それを過ぎると、問題は「私たちが壊す可能性のある変数構文について他に何がわからないのか」ということです。

コンセンサスがこれに${...}構文を強制することである場合、この構文を使用する私のような人々（私はそれを_たくさん使用します）がノイズをオプトアウトできるように、ここでOptionalFeaturesのサポートをいただければ幸いです。

ここで言い換えているので：
「論理は、多くの人のニーズが少数の人のニーズを上回っていることを明確に示しています。」 -スポック

したがって、数学を実行すると、これを実行しない具体的な理由がいくつかあり、これを実行する理由は1つだけです（一部のユーザーにとっては、より簡単な場合があります）。

@StartAutomating ：複数の理由があり、それらは曖昧ではなく具体的​​です。 また、これの目標の1つは、コードの単純さです。 変数名を{}ラップする必要があることは、その目標に直接反します。

私はこれについて@ mklement0と@KirkMunroと${...}?構文は不自然で不必要に複雑だと思います。 すでに重大な変更がありましたが、この場合、明確さと引き換えに支払うのは少額です。

@StartAutomating

1. さらに、予期しない変数名に問題があるほとんどの人は、$ {}構文を学習します（すでにアンダースコアで自然にヒットしています）。 「この機能を使用したい人」と「$ {}構文をすでに知っている人」のベン図の重複はほぼ100％になると思います。

これは持ちこたえません。 アンダースコアは、変数名の有効な文字です。

@ vexx32

コードが書かれたときにそれが期待されていたことは私には明らかなようです

いいえ。

文字を交換しますか？ $foo.?Propertyは衝突していないように見えます。これは、疑問符で始まるプロパティ名はすでに引用符で囲む必要があるためです。

PS C:\> $foo = [pscustomobject]@{'?'=1; '?name'=2}
PS C:\> $foo.?name
At line:1 char:6
+ $foo.?name
+      ~
Missing property name after reference operator.
    + CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : MissingPropertyName
PS C:\> $foo.'?name'
2

@HumanEquivalentUnitは、残念ながら、C＃や他のいくつかの言語で使用されている老舗の?.構文との永遠の混乱を招きます（また、インデクサーの代替形式（ ${arr}?[0]を見つける必要があります） $arr[0]?ようなものは、三項演算子との混乱を招きます）

きちんとした解決策はありません。

1. 不明な数の人が使用していますか？ 変数名の最後。 これはオプションの機能ですが、「これらのスクリプトを実行する場合はオンにしないでください」と言うことができますが、それをオンにする人は、ソースから取得した現在および将来のスクリプトを確認する必要があります。
2. 代替構文は、C＃からあまり強力ではないものをインポートしているため、優れたオプションではありません。
3. #requiresに基づいて動作を変更することは、保存されたスクリプトの外部では機能せず、誰かがタグを設定せずに長いスクリプトからコードをコピーするとすぐに失敗します。
   4. (dir *.ps2)?.countと(dir *.ps1)?.countは、オペランドが変数である必要がないことを示しています。
   ($Host)?.toString() / ($null)?.toString()すると、名前を中かっこで囲む必要がなくなります。 それはまだ余分なキーストロークですが、より論理的で醜いものではありません。

1. #requiresに基づいて動作を変更することは、保存されたスクリプトの外部では機能せず、誰かがタグを設定せずに長いスクリプトからコードをコピーするとすぐに失敗します。

これは、以前のバージョンでサポートされていない機能を使用する_any_コードに適用されます。
これが最優先の懸念事項である場合、新しい言語機能や新しいコマンドレット/コマンドレットパラメーターは導入されません。

（うまくいけば、古いコードでは少なくともSet-StrictMode -Version 1が有効になっています。この場合、 var?という名前の変数が存在しないため、 $var?.fooは大音量で失敗します）。

1. 名前を中かっこで囲む必要がなくなります。

置換(...)ため{...}わずかしか改善されています。

使用する追加の構文が何であれ、ここでの問題は、追加の構文の_必要性_です。入力の利便性だけでなく、_賢明な期待_を満たすためにも、そのまま機能する必要があります。

1. #requiresに基づいて動作を変更することは、保存されたスクリプトの外部では機能せず、誰かがタグを設定せずに長いスクリプトからコードをコピーするとすぐに失敗します。

これは、以前のバージョンでサポートされていない機能を使用する_any_コードに適用されます。
これが最優先の懸念事項である場合、新しい言語機能や新しいコマンドレット/コマンドレットパラメーターは導入されません。

それは私が意図したことではありませんでした。 さらに上に、＃requiresが指定されたpwsh 7を必要とする場合、処理が異なる可能性があるという提案がありました。 #requiresを入力した場合にのみ、新しい動作を点灯します良くありません。

（うまくいけば、古いコードでは少なくともSet-StrictMode -Version 1が有効になっています。この場合、 var?という名前の変数が存在しないため、 $var?.fooは大音量で失敗します）。

私の経験では、Set-Strictmodeはあまり使用していません。 （a）それなしのデフォルトは「正しい」という仮定があり、（b）それがオフになっていることに依存するものを使用する頻度が高すぎるためです。 これらの演算子の一般的な使用法です。 いずれにせよ、問題は$ varの古いコードですか？ 存在し、fooプロパティを持っていますが、コードは$ varを探します... $ varが存在しないためにstrictmodeが設定されている場合、新しい処理によってエラーが発生する可能性があります...。

1. 名前を中かっこで囲む必要がなくなります。

置換(...)ため{...}わずかしか改善されています。

はい。 （$ x）は$ {x}よりわずかに優れていますが、わずかです。 （ Get-user "Bob")?.disable()はよりも優れています

$u = get-user "bob" 
($u)?.disable

使用する追加の構文が何であれ、ここでの問題は、追加の構文の_必要性_です。入力の利便性だけでなく、_賢明な期待_を満たすためにも、そのまま機能する必要があります。

はい。
$var. fooホワイトスペースで動作します。 ${foo} ?.bar()はそうではありませんか？ 関数名またはエイリアス名で許可されます（？。は両方で有効です）。 物事を壊さずに既存の構文ルールにC＃構文のビットをラッシングすることは、常に実用的であるとは限りません。「これはC＃で利用可能です...」は、「はい。必要に応じてC＃がどこにあるか知っています」という答えに値する場合があります。
:-)

SemVerの互換性を維持するには、これをメジャーリリース（できれば7.0.0 ）で実行する必要があります。

上記の私の提案も参照してください（

@ ExE-Bossはい、＃requiresに応じて最初に聞こえるのは良い考えではないかもしれないと言ったときに私が言及したのはあなたのコメントでした。
はい、既存のスクリプトを壊す場合は、メジャーバージョンが変更されたときに実行する必要があるため、これを迅速に実行するか、V8を待つ必要があります。

これらはまだ実験的な機能であり、RC-1ではデフォルトでオフになっています。これは出荷時の製品でも同じであると思います。 これにより、動作を変更することができます（または、2番目の実験的な機能にすることもできます）。特定の文字で終わる変数を作成しようとすると、ブロック/警告する必要があります。 それを有効にしてから、私に責任を負わせる誤った変数名のスクリプトを使用したい場合-もちろん、ダウンロードしたスクリプトは「壊れた」ように見え、「実験的」バナーの下でより許容できることを意味します。

私は真面目なPowerShell開発者ではありません。 私はバグの解決策を探してここに来ましたが、たまたまこの問題に遭遇しました。 コマンドラインスクリプトでは、主にbashを使用します。 私はおそらく、MicrosoftがPowerShell Coreに切り替えるよう説得しようとしている人口統計にいます。クロスプラットフォームの開発者は、bashよりも簡単なスクリプト言語を必要としています。

PowerShellの構文に関連する決定の多くは、主にPowerShell開発者ではない人々にとって直感的ではないことがよくあります。 前回PowerShellを深刻な目的で使用したとき、null合体演算子、または代わりに使用できる3項演算子がないことに愕然としました。その結果、

@StartAutomatingは言った：

非常にオタクな人は別として、$ {obj}？。Method（）または$ obj？.Method（）は少し上昇すると思います。 そこにヌルを管理する方法についての10年間のガイダンスがウェブ上にあります、そして私は多くの人々がv7の時流に乗るためだけにif（$ obj）{$ obj.Method（）}から切り替えるのを見ません

私はn = 1ですが、PowerShell以外の開発者として、私は強く反対します。 新しい ？ 構文は、PowerShellに触れる人が数か月に1回程度であっても、すぐにわかるものであり、将来、代替手段の代わりにPowerShellを使用する可能性が確実に高まります。 次に、下位互換性のためにいくつかのクレイジーな{}構文が必要であることがわかった場合は、目を転がして、すでに使用していたものに戻ります。

ここでは、下位互換性が強調されていることを理解していません。 PowerShell Coreは、.NET Coreにない.NETの部分を使用していたため、既存のスクリプトのほとんどをすでに壊していました。 （私はそれについて不平を言っていません--.NET Coreは素晴らしいですが、下位互換性を壊すつもりなら、今がチャンスです。）

まず、私の最初のフィードバックが誤解の混乱を引き起こしたと思います。

私の推測では、$ {}は_PowerShell開発者にとってそれほど奇妙なものではない_。なぜなら、変数に？を埋め込んだことがあれば、この構文形式をすでに知っている必要があるからだ。 または、文字列にアンダースコアを付けます。

この構文はPowerShell以外の開発者にとって扱いにくい可能性があることを多くの人に思い出させてくれてありがとう。

フィードバックの2番目の部分は、ミックスで失われた可能性があります。null合体に代わる他の方法がPowerShellに以前から存在し、広く使用されているため、この機能が_既存のPowerShellユーザーで_どの程度向上するかわかりません。 あなたは入って来て、「これは私がPowerShellを使い始めるために必要なことの1つです」と言いたいのですが、私はあなたの意見に異議を唱えることはできません（言語の木を探しているクールな機能の森が欠けていると言うかもしれませんが親しみやすさ）。

私のフィードバックの3番目のビットは、不釣り合いに吹き飛ばされたようです。 $ IsThisRightのような名前の変数を時々使用したことがある人の1人として話しますか？ =テスト-何か、この変数の制限に関する潜在的なニュースを聞いたときの私の最初の反応は、「まあ、いくつかの変数の名前を変更する必要があると思いますが、とにかくそれほど多くは得られませんでした」でした。

したがって、スレッドを言い換えて終了しようとすると、次のようになります。

1. 私見、$ {}は、おそらく_existing_PowerShell開発者にとってそれほど奇妙な構文ではないでしょう。
2. この機能はすばらしいと思います。 私にとって、これは言語に精通したゲートウェイドラッグであり、このスレッドを読んでいるすべての人に、ifs / foreaches / whilesなどを割り当てる方法を学ぶことを強くお勧めします。
3. 影響を受けた著者の1人として、私は？からそれほどミッションクリティカルなものを得ていません。 変数の最後で、コードを変更することに反対します。

または、簡潔に言うと、次のようになります。

必要に応じて、この変更を行ってください。 このレースには小さな馬がいます。 これを行うことにした場合は、変数に？を付けて名前を付けた他の人がいるように、変更を明確にブロードキャストしてください。 それに応じて更新できます。

フィードバックの2番目の部分は、ミックスで失われた可能性があります。null合体に代わる他の方法がPowerShellに以前から存在し、広く使用されているため、既存のPowerShellユーザーでこの機能がどの程度向上するかわかりません。

私は間違いなくそれに同意します、そして私はあなたの意見を否定したくありません。 そのような重大な変更を加えることは常に困難です。特に、その言語をすでに頻繁に使用している人々にとって、その代替手段が直感的である可能性がある場合はなおさらです。

あなたは入って来て、「これは私がPowerShellを使い始めるために必要なことの1つです」と言いたいのですが、私はあなたの意見に異議を唱えることはできません（言語の木を探しているクールな機能の森が欠けていると言うかもしれませんが親しみやすさ）。

ええと、PowerShell以外のほとんどの開発者は実際にはこれらの会話に参加していないと感じました。これに偶然出くわしたのは、まったくの偶然です。 私のPowerShellの使用法は、ライブラリやオープンソースツールを作成している人とは大きく異なる可能性があります。 私は、PowerShellを派手なフレームワークとして使用するのではなく、奇妙なタスクをできるだけ速く実行するために使用している人の視点を与えるだけだと考えました。 それは他の意見を否定することを意味するものではありません-それはおそらくここではそれほど頻繁に見られないという観点からの単なる別の意見です。

PowerShellの使用を開始するために必要なのは、null処理の改善だけではありません。それは、2番目のことです。 1つ目はクロスプラットフォームのサポートでしたが、それがどこまで進んでいるかに非常に感銘を受けました。 個人的には、特定のタスクを実行する言語を選択するとき、構文糖衣構文は私にとって大きな問題です。構文によって、実行していることが簡単になります。 多くの人が維持する必要のあるものを書いている場合は、もっと冗長にしたいと思うでしょう。 ただし、管理タスクまたはDevOpsタスク用の簡単なスクリプトを作成している場合は、nullなどをすばやくテストする方法が必要です。

私のフィードバックの3番目のビットは、不釣り合いに吹き飛ばされたようです。 $ IsThisRightのような名前の変数を時々使用したことがある人の1人として話しますか？ =テスト-何か、この変数の制限に関する潜在的なニュースを聞いたときの私の最初の反応は、「まあ、いくつかの変数の名前を変更する必要があると思いますが、とにかくそれほど多くは得られませんでした」でした。

下位互換性を優先することは、常に公正な議論です。 ただし、この特定のケースでは、とにかくCoreへの移行により、多くのPowerShellスクリプトが壊れそうになっているようです。 下位互換性が定期的に壊れるとイライラしますが、一度に壊れる変更が発生することを支持します。これはおそらく良い時期であることを意味します。

まったく新しい人口統計、つまりWindows中心ではない開発者をターゲットにしようとしているシナリオでは、すでに存在するものと競争するために、いくつかの重大な変更を加える必要があるかもしれません。

これを行うことにした場合は、変数に？を付けて名前を付けた他の人がいるように、変更を明確にブロードキャストしてください。 それに応じて更新できます。

明確にするために、私はこの機能をオプトインする必要があることに問題はありません-それは私がPowerShellを使用することを思いとどまらせることはありません。 私はすでに、bashスクリプトの先頭にたくさんのsetコマンドが必要になることに慣れています。 理想的とは思いませんが、十分に文書化されている限り、PowerShellを使用するという私の決定にはほとんど影響しません。

個人的には、特定のタスクを実行する言語を選択するとき、シンタックスシュガーは私にとって大きな問題です。

その後、あなたは正しい言語に来ました！ PowerShellは、シンタックスシュガーを使用した積極的なサクリンです。

知らない人を教育するために、PowerShellでいくつかの方法を「nullcoalese」することができます。
〜$ ListWhereNotNull = $ null、1、2、$ null、3 -ne $ null＃これにより、各アイテムがnullでないことが確認され、1,2,3のリストが返されます。$ FirstNonNull = @（$ null、1、$ null、2 -ne $ null）[0]＃これは最初の非nullを返します$ lastNonNull = @（$ null、1、2、$ null -ne $ null）[-1]＃これは、負のインデックスを使用して、最後の非nullを返します$ TheObjectPipelineWay = $ null、1、$ null、2 | Select-Object -First 1$ TheAssigningForeachWay = foreach（$ null、1、2、$ null、3、4の$ item）{if（$ item -ne $ null）{$ item;



今のところこれで十分ですが、言語構文が非常に柔軟であることのポイントを証明するはずです。 これらのデモはすべて、PowerShell1.0までさかのぼって機能します。

ただし、この特定のケースでは、とにかくCoreへの移行により、多くのPowerShellスクリプトが壊れそうになっているようです。

これであなたは間違っています。 Coreには実際には構文を壊す変更がほとんどなく、コアで問題なく動作すると思われるよりも多くのモジュールがあります（+ -LinuxとWindowsのパス/改行に関するいくつかの問題）。 より実用的には、Windowsプラットフォーム固有のAPI依存関係がある場合、モジュールがCoreで動作する可能性は低くなります（たとえば、LinuxでWPFラッパーを動作させるために息を呑むつもりはありません）。

構文を変更しても、どちらの方法でも問題はありません。最新の応答の2つのアサーションに対処し、呼び出す必要があると感じました。

Re：糖衣構文、私の皮肉な心は映画「スナッチ」を引用しています：「私はすでに十分に甘いです」
Re：コアの変化の可能性を打ち破る：今はほとんどないので、できる限りそのように保ちましょう。

@StartAutomating ：あなたは私が撃つことができないと言っていますか？ もっと砂糖を入れる場所がまだあるので😜

知らない人を教育するために、PowerShellでいくつかの方法を「nullcoalese」することができます。

私はそれを理解しました（それは私が書いた私自身の答えです）が、それは恨みのように感じました。 これは多くの可能性を秘めたクールなアイデアですが、そのStack Overflowの回答に対するあるコメント者が指摘したように、評価は短絡しません。 ?.演算子は、呼び出し/プロパティをチェーンするときに、これが通常は問題ではなくなったことを意味します。 しかし、2013年には利用できませんでした。それでも、これらの例では非常に多くのことが行われており、コメントで人々がその混乱をどのように感じたかを見ることができます。 これらの例がシンボルごとに何をするのかを正確に分析する必要がありました。

これであなたは間違っています。 Coreには実際には構文を壊す変更がほとんどなく、コアで問題なく動作すると思われるよりも多くのモジュールがあります（+ -LinuxとWindowsのパス/改行に関するいくつかの問題）。 より実用的には、Windowsプラットフォーム固有のAPI依存関係がある場合、モジュールがCoreで動作する可能性は低くなります（たとえば、LinuxでWPFラッパーを動作させるために息を呑むつもりはありません）。

私は、実際に適切な統計を調べて収集するのではなく、この点に関する経験から話しているだけです。 たとえば、Core以前では、 [System.Web.Security.Membership]::GeneratePassword(32, 6)使用してパスワードを生成できましたが、 System.WebはCoreでは使用できません。 （おそらく古いSystem.Web.dllをロードできることはわかっていますが、ロードする必要がない場合はロードしたくありません。）構文の変更は、APIが欠落しているよりも実際に解決するのが簡単です。 devkit用に大量のDockerシークレットを生成することは、簡単なスクリプトを使用するのに最適な場所のように思えますが、PowerShellCoreではbashよりも驚くほど冗長です。 もちろん、bashのソリューションはかなり醜いように見えることがよくあります。

Re：糖衣構文、私の皮肉な心は映画「スナッチ」を引用しています：「私はすでに十分に甘いです」

場合によります。 PowerShellが非常に快適だと感じることがあります。 nullに対処することは、私が通常そのように感じない重要な領域の1つです。ただし、多くの言語で同じことを言います。 また、従来のインラインPowerShell if-elseステートメントは、三項演算子やbashの&&および||チェーンと比較して扱いにくいと感じています。 これは、何年も前にPowerShellから離れる原因となった重要な問題の1つであるため、言及する価値があると思いました。

一方、私は日常的に多種多様な言語を扱っており、何を書いていても、「これは言語Xの方がはるかに簡単だろう」と常に考えています。私は言語Xを使用していますが、「これは言語Yの方がはるかに簡単だろう」と考えています。 でもねえ、それを大声で言う機会があり、多分言語の方向性を揺るがすなら、私はそれを取ります。

私はここで考えを変えることにあまり興味がなく、ただ別の視点を追加するだけです。

@StartAutomating ：あなたは私が撃つことができないと言っていますか？ もっと砂糖を入れる場所がまだあるので😜

私はいつも新しいシンタックスシュガーが大好きです！ 私はハロウィーンでトリックオアトリートをする子供のようなプログラミング言語を選択します。

@Zenexer：私は本当にPowerShellのような、私は。 私は幸運にもPSを広範囲にそして毎日仕事で行うことができます。 私は柔軟性、特に.NETとの共生が大好きです。 そのため、私はその方向を気にし、 ${...}?構文を受け入れるのが非常に難しいのです。

良い点ですが、いくつか明確にしておきます。

良くも悪くも、これまでのPowerShellはセマンティックバージョニングを使用していません。
新しいメジャーバージョンは、下位互換性への確固たるコミットメントを備えた_new_機能のみをもたらしました。
クロスプラットフォームへの移行が原因の一部として、重大な変更がCoreに忍び寄り始めました。
メジャーバージョンv7.0は、下位互換性の_増加_を通知するために選択されました。これは、WindowsPowerShellの実行可能な代替手段を提供する試みです。

多くの歴史的な問題は、既存のコードを大幅に壊さずに修正することはできないため、オプションの（オプトイン）機能としてのみ提供できますが、
バケット3の破壊的な変更は、常にオプションである必要があります。既存のコードを破壊する_可能性がある_修正/改善を行いますが、実際にはそうなる可能性は低いです。 結局のところ、言語を改善することは価値があります。

OPで議論されているように、手元のケースはバケット3の変更として私を襲います。 _some_スクリプトが壊れることはわかっていますが（ @StartAutomatingはスクリプトを修正する方法を知っています）、データはそのようなケースが非常にまれであることを示唆しています。

なぜ珍しいのですか？

変数名で?を使用することはほとんどの人にまったく起こらないので、もしそうなら、彼らはそれが_ {...}なしで動作することを期待すべきではありません_：以下のすべてがでのみ動作する場合{...} 、 ?で異なると予想されるのはなぜですか？： . , ; （ :は常に次のように解釈されるため、まったく使用できません。ドライブセパレーター）

{...}も必要とせずに$var?や$va?rなどの名前を許可することは、問題を要求する寛容さであり、問​​題が発生しました。それは、この場合のように、言語。

C＃に触発された3つの新しい関連機能（少なくとも構文形式で関連）があります：

• 三項条件-7.0では真正な機能になります
  
  
  
  • (Get-Date).Second % 2 ? 'odd' : 'even'
  
  
• ヌル合体演算子-7.0では真正な機能になります
  
  
  
  • $var ?? 'default'および$var ??= 'default'
  
  
• ヌル条件演算子（目前の問題）は、7.0の_実験的_機能になります
  
  
  
  • $possiblyNull?.ToString()
  
  

それらはすべて構文の一部として?を持っており、 ?.最も明白ですが、それらはすべてレガシー$var?解析の負担の影響を受けます。

• $var?1:0ようなものはコードゴルファーにのみ関心があると主張することもできますが、 ?に構文機能がある場合は問題なく機能します。現在、 ?前に_space_を使用する必要があります。

• 対照的に、誰かが$var??='bar' （おそらく$baz = $foo??$bar ）を試みるのは合理的であると私は思いますが、これも現在スペースを必要とします。

つまり、現在の$var?解析に固執すると、（程度は異なりますが）_3_の新機能が妨げられ、そのうちの2つはすでに一般に利用可能です（実験的ではありません）。

{...}を要求する際の問題は、入力の不便さだけではありません。そもそも、必要性を予期せず、後で必要性を忘れる（微妙な誤動作の可能性がある）ためです。それはとても直感に反します。

@ ExE-Boss、バージョン条件付きの動作を実装すると問題が発生するという

@ mklement0 ：それは不自然/直感に反する/あなたの名前です。 ブラケットは硬く、中括弧はさらに硬くなります。 この場合、それらは必要ありません。

@ mklement0合意が成立しているよう

PowerShellにC＃構造を追加しても、まだ完全に勝ち取られていません。 キーボードに十分な記号がないという問題がすでに多くの場所で発生しています。 ">" "より大きい"、または "リダイレクト"ですか？ "="割り当てまたはテストの平等です（異なる言語では、割り当てに：=を使用するか、平等に==を使用します）。 言語間をジャンプする人々は、 -eqまたは-gt使用を忘れてしまい、私たちはそれに固執します...は+算術加算、または文字列/配列の連結です。 *は乗算とワイルドカードの両方です。 ％はモジュロであり、 forEach-object.エイリアスです。

貧しい ？ Where-Object.のエイリアスであり、自動変数の名前です。 しかし、 Get-Alias ?またはGet-Variable ?実行してみてください...そうすると、ワイルドカードの役割を果たします。

Get-PSdriveを実行すると、「変数」などの名前の末尾に「：」がないことがわかります。名前に：を追加すると、ドライブとして扱われます。 もちろん、あなたが"$drive="C" を書いて、それに続いて"$drive:temp"を参照しない限り、PowerShellを初めて使用する人（および、PowerShellについて考えていない場合は、一部の古い人）は、自分たちがいることを知って困惑します。名前付きスコープ「ドライブ」を発明しました。

したがって、それに対して...「：」と「？」をさらに使用して新しい構文を作成すると言うかもしれません。 ばかじゃないの？'
IIRC、ツイッター@BrucePayは、三項演算子を「あまりPowerShellyではない」と説明しており、私は同意する傾向があります。 しかし、「C＃のように」という声がその日を勝ち取りました...

ほとんどの人は$PSEdition.length -gt 2を書くでしょう
ただし、 $PSEdition. length-gt2も機能します（2つの半分の間に改行を入れることもできます）。 "。" また、「現在のディレクトリ」、「このスコープで実行」、「メンバー」として機能するオーバーロードもあります。ただし、PS V1-V5では、先頭にスペースを必要とする演算子は考えられません。 「。」 1つが存在する場合、破壊するのは奇妙です。 ただし、解析するために、三項演算子には先頭のスペースが必要になる場合があります
$host.debuggerEnabled?0:1は「？」 プロパティの一部とは見なされません
$IsCoreCLR?0:1は「？」 変数名の一部であると見なされます。

null合体演算子についても同じことが言えます。
$null?? "default"にはスペースが必要です$true.length?? "default"は必要ありません。

問題の上部にある元のユースケースを少しの間片側に置きます。 上記のケースは、何かが完全に機能していないことを示しています。 「？」を含む変数名の場合は修正されます。 「。」を含む名前のようにブレースする必要がありました。 または「+」または「：」、および「？」のメインユーザーである@StartAutomating 名前では、それは_処理できるブレーク_だと考えています。 nullメンバーに到達する前に、「すでにそれを行う方法を見つける」ように聞こえます。

必要な実験的機能を導入するための短い時間枠があると思いますか？ 名前で囲まれ、その機能がオンの場合（デフォルトである必要があります）、すべて新しいですか？ 演算子はそれに応じて解析する必要があります。 その機能がオフの場合にのみ、パーサーはこれらの演算子でスペースまたは中括弧を必要とします。これは重大な変更であり、オプションが設定されていない限り、一部のスクリプト（定量化できない小さな数値）が破損します（変数名を許可しないと$ IsItが防止されます） ？.tostring（）はスクリプトの最初のエラーであるため、スクリプトは失敗するはずであり、危険なほど実行されないはずです）。 理想的には、ポイントリリースでは発生しないはずです（PowerShellが実際にsem-verを使用していないことについては正しいですが、それでも良い原則です）

{...}を要求する際の問題は、入力の不便さだけではありません。そもそも必要性を予期せず、後で必要性を忘れてしまうことです（微妙な誤動作の可能性があります）。とても直感に反します。

これは良い点であり、実際には${...?}について私を悩ませることになります。 {}を使用することを知っていても、最終的には忘れてしまう可能性が高く、構文的にはまだ有効であるため、最初は明らかではない微妙なバグが発生する可能性があります。 $var??='bar'はその良い例ですが、私は通常、間隔にかなり注意を払っています。

おかげで、 @ jhoneill 、これは、PowerShellで多くの2倍（3倍、...）の役割を果たしているシンボルの数を示す良い例です。
ほとんどの場合、次の理由により、すべての使用法を認識していれば、それは問題ではありません。

• さまざまなコンテキスト（たとえば、演算子としての*とワイルドカード文字としての* ）
  
  
  
  • ?のさまざまなコンテキストには、実際には、特定の抽象化レベルで共通点があります。 Get-ChildItem | ? Target 、 $var?.Target 、 $? ?を考えることができます。 $? 、 $var ?? 'none'はすべて一種の_question_を含み、したがって_test_または_conditionalbehavior_を含みます。
  
  
• 賢明なポリモーフィックな振る舞い（たとえば、 +が文字列との連結を実行する）。

問題のある例は& （呼び出し演算子とバックグラウンド演算子）です。これは、_position_のみに応じて、異なるセマンティクスで同じコンテキストで使用されます。

「？」を含む変数名の場合は修正されます。 「。」を含む名前のようにブレースする必要がありました。 または「+」または「：」

確かに、繰り返しになります。変数名で?を使用する機能がなくなることはありませんが、今後は{...}を使用する必要があります： ${var?} = @{ foo=1 }; ${var?}?.foo

あなたが示すように、誰かの観点からは、 ?が有効な文字であることを賢明に期待していません。 .が正当な例外です。 ?はWhere-Objectとして）、正当な理由があります。後にスペースを必要とするgci|?targetは機能しません）、コマンド名は空白で引数から区切る必要があります。

.とメンバー名（ $obj. foo ）の間に空白を入れることができることは、主に複数行のステートメントで意味がありますが、おそらく他の言語でよく知られているより読みやすい形式は（また） . _前_に空白を許可します：

# This does NOT work - the . must be *immediately after* the expression / member
(Get-Date)
  .ToUniversalTime()  
  .TimeOfDay

そうすることができることは、_next_行に|を配置する最近追加された機能を反映します。

 # Already works in PS Core
Get-Date
  | % ToUniversalTime
  | % TimeOfDay

ただし、これにより、ドットソーシング演算子として.れ、 .で始まるコマンド名が使用されると、解決できないあいまいさが生じます。ただし、可能性は低いです。 （たとえば、改行の. fooは、プロパティアクセス、またはfooという名前の関数またはスクリプトをドットソースするコマンドである可能性があります（ $env:PATH ）。 ; .fooは_command_の名前である可能性があります）。

@KirkMunroの複数行継続RFCは、_commands_が複数行にまたがることを許可することに焦点を当てていますが、次善の解決策を提供します-https ください。

実験的機能がデフォルトでオンになっている場合：幸い、_preview_リリース（リリース候補ではない）は、デフォルトで_all_実験的機能をオンにするようになりました。 ただし、 Enable-ExperimentalFeature 、 -Scopeまたは-Scope CurrentUserを使用して、そこで有効にした機能を使用して実行したことがある場合は、これが永続的に上書きされることに注意してください。

@ mklement0私は基本的にそのすべてに同意しますが、私たちはあなたがそこに持っている余分な断片でこの特定の議論を少し

?を通常の変数名の文字として許可し続けることは、ユーザーにとってせいぜい非常に混乱することに同意します。文字を使用すると突然空白が敏感になり、少なくとも歴史的には、変数名に_ever_はないと思います。過去に空白に敏感でした。

そのあいまいさを導入することは、重大な変更を加えて変数名での?使用を禁止することよりも問題だと思います。 重大な変更により、PSSAルールを簡単に作成して、構文が許可されなくなったことを作成者に警告できます。 ただし、その逆はそれほど簡単には当てはまらず、重大な変更とは異なり、必ずしもエラーになるとは限りません。 ユーザーが間違った変数を誤ってサイレントに参照してしまう可能性が非常に高く、それが自分のしていることであることがわかりません。

@ PowerShell / powershell-committeeがこれについて話し合い、PowerShellコーパスのスクリプトを分析し、疑問符で終わる変数名がかなり使用されていました。 そのため、PowerShell変数名を中括弧で囲むことはできません。これは、変数名を他の文字（文字列内など）と区別するための既存の言語機能です。

スクリプトのPowerShellコーパスを分析しましたが、疑問符で終わる変数名がかなり使用されていました。

ありがとう、@ SteveL-MSFT-この分析の結果を共有していただけますか？

ええ、私はそのいくつかを見てみたいと思います。なぜなら、一部のコミュニティメンバーが独自の分析を行い、そのような結果に近いものが何も得られなかったことを知っているからです。

また、使用した結果と方法も見てみたいと思います。 昨夜、自分のマシンで完了するのに約6時間かかったASTを使用して、 PowerShellコーパスの独自の分析を行いました。 Windows Defenderがファイルを検疫しているため、解析できないファイルが少数ありました。

疑問符で終わる8つのファイル全体で11の一意の変数名が見つかりました（8846回表示された$？を除く）。 408,423個のファイルに合計1,895,983個の一意の変数がありました。 つまり、コーパス内のすべての一意のPowerShell変数の0.0006％に、疑問符で終わる変数名があります。

8つのファイルと11の一意の変数は次のとおりです。

File                 : C:\Temp\PowerShellCorpus\Github\alanrenouf_PowerActions\Kill-VM.ps1
QuestionMarkVars     : vParam?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\Github\anthonywlee_PowerShell\Send_Notification.ps1
QuestionMarkVars     : To?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\Github\aspear_My-PowerCLI-scripts\my-labotomize-vms.ps1
QuestionMarkVars     : vParam?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\Github\jlundstrom_Scripts\Powershell\7Zip SFX Creator\Build.ps1
QuestionMarkVars     : Title?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\Github\pslaughter_Working\Setup-Host.ps1
QuestionMarkVars     : HostIp?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\Github\stevenayers_PowerShell-Scripts\Random Functions\Add-OutlookConferenceRegionNumber.ps1
QuestionMarkVars     : {key1?, key2?, key3?, key4?}
QuestionMarkVarCount : 4

File                 : C:\Temp\PowerShellCorpus\Github\unixboy_powershell-stufff\stopvm.ps1
QuestionMarkVars     : vParam?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\PowerShellGallery\PsHg\0.6.2\PsHg.psm1
QuestionMarkVars     : PsHg?
QuestionMarkVarCount : 1

これは、レポートの生成に使用されるスクリプトです。

Get-ChildItem -Path C:\Temp\PowerShellCorpus -Include *.ps1, *.psm1 -File -Recurse | ForEach-Object -Parallel {
    try {
        $content = $PSItem | Get-Content

        $ast = [System.Management.Automation.Language.Parser]::ParseInput($content, [ref]$null, [ref]$null)
        $variables = $ast.FindAll({$args[0] -is [System.Management.Automation.Language.VariableExpressionAst ]}, $true)

        # First query because I forgot to exclude $? variables
        # $nonQuestionMark = $variables | Where-Object VariablePath -notmatch '\?$' | Select-Object -Unique
        # $QuestionMark = $variables | Where-Object VariablePath -match '\?$' | Select-Object -Unique

        $nonQuestionMark = $variables |
        Where-Object VariablePath -notmatch '\?$' |
        ForEach-Object { $_.VariablePath.UserPath.ToString() } |
        Select-Object -Unique

        $QuestionMark = $variables |
        Where-Object { $_.VariablePath -match '\?$' -and $_.VariablePath.UserPath -ne '?' } |
        ForEach-Object { $_.VariablePath.UserPath.ToString() } |
        Select-Object -Unique

        $output = [pscustomobject]@{
            File = $PSItem
            QuestionMarkVars = $QuestionMark
            QuestionMarkVarCount = $QuestionMark.Count
            NonQuestionMarkVars = $nonQuestionMark
            NonQuestionMarkVarCount = $nonQuestionMark.Count
        }

        $output
    }
    catch {
        throw
    }
}

このレポートの生成方法に問題がある場合はお知らせください。 これは、監査をテストするために使用されるスクリプトの例です。

$abc = 'test'
$isAwesome? = $true
$?

$test = {
    $?
    $isabc? = { $adce? = 'test' }
    ${def?} = 123
    ${is a bad var name?} = $isabc?
}

結果：

File                    : C:\temp\variable.ps1
QuestionMarkVars        : {isAwesome?, isabc?, adce?, def?, is a bad var name?}
QuestionMarkVarCount    : 5
NonQuestionMarkVars     : {abc, true, test}
NonQuestionMarkVarCount : 3

彼らが数学の授業で言うように、「あなたの仕事を見せてください」😄

素晴らしい探偵、 @ ThomasNieto-ありがとう。

フォーム${...}が提案された変更で引き続き機能することを考えると、さらに多くのケースを排除できる可能性があると思います。たとえば、心配する必要があるのは$isAwesome?であり、 ${isAwesome?}ではありません。

サンプルファイルの場合：

$variables.Extent.Text.Where({ $_ -match '(?<!\$)\?$' }) | Select-Object -Unique

私たちは得るだけです：

$isAwesome?
$isabc?
$adce?

つまり、 ${def?}と${is a bad var name?}考慮する必要はありません。

PS：スクリプト全体を単一の文字列として読み取るには、 $PSItem | Get-Content -Rawを使用する方がおそらく良いでしょう。

@ mklement0正解です。投稿する直前にこれらのケースを追加して、スクリプトが中括弧表記の変数をまとめて除外しないようにしました。

推奨事項でスクリプトを更新した後、テストファイルは期待どおりに次の出力を生成します。

File                    : C:\temp\variable.ps1
QuestionMarkVars        : {isAwesome?, isabc?, adce?}
QuestionMarkVarCount    : 3
NonQuestionMarkVars     : {abc, true, test}
NonQuestionMarkVarCount : 3

これらの8つのファイルに対して更新されたスクリプトを実行しましたが、いずれも中括弧表記を使用していないため、提案された変更によって11個の一意の変数が影響を受けます。

更新されたスクリプト：

Get-ChildItem -Path C:\Temp\PowerShellCorpus -Include *.ps1, *.psm1 -File -Recurse | ForEach-Object -Parallel {
    try {
        $content = $PSItem | Get-Content -Raw

        $ast = [System.Management.Automation.Language.Parser]::ParseInput($content, [ref]$null, [ref]$null)
        $variables = $ast.FindAll({$args[0] -is [System.Management.Automation.Language.VariableExpressionAst ]}, $true)

        $nonQuestionMark = $variables |
        Where-Object VariablePath -notmatch '\?$' |
        ForEach-Object { $_.VariablePath.UserPath.ToString() } |
        Select-Object -Unique

        $QuestionMark = $variables |
        Where-Object { $_.VariablePath -match '\?$' -and $_.VariablePath.UserPath -ne '?' -and $_.Extent.Text -match '(?<!\$)\?$' } |
        ForEach-Object { $_.VariablePath.UserPath.ToString() } |
        Select-Object -Unique

        $output = [pscustomobject]@{
            File = $PSItem
            QuestionMarkVars = $QuestionMark
            QuestionMarkVarCount = $QuestionMark.Count
            NonQuestionMarkVars = $nonQuestionMark
            NonQuestionMarkVarCount = $nonQuestionMark.Count
        }

        $output
    }
    catch {
        throw
    }
}

ありがとう、 @ ThomasNieto-パーセンテージを0.0005％まで下げることができると思っていました...（冗談です）。

それで、委員会は別のものを使用したに違いありません-プライベート？ -コーパス。

したがって、目前の問題を決定することに加えて、疑問が生じます：公開されているコーパスを更新する必要がありますか？ 正式にメンテナンスされていますか（現在は2017年7月26日付け）？

@ SteveL-MSFT、明確にしていただけますか？

@ mklement0切り上げたので、少しだけ気分を良くしたい場合は、実際には0.00058％です😄

https://github.com/PowerShell/PowerShell-RFC/pull/223#discussion_r318340339で、 @ adityapatwardhanは、私が使用したのと同じ公開コーパスを使用して分析を行い、62％で、変数が疑問符で終わっています。 彼がどのようにしてそのパーセンテージを思いついたのかについての反応は見られませんでした。 PS委員会はその分析を使用してこの要求を決定しましたか？

リンクされたコメントを見ると、 @ adityapatwardhanが言っていることは、_名前に?が含まれるすべての変数の中で_ 62％が名前の_last_文字として?を持っていることだと思います。

対照的に、（中括弧のない） ?変数で終わる実際の有病率の分析（全体的な変数使用量のパーセンテージとして）は、はるかに関連性が高いようです。

この時点で、委員会は「やりたくない」と言っているように聞こえますが、その場合、結果として不格好で使用されなくなるのであれば、なぜこの機能を使用するのでしょうか。

@ThomasNieto同様に、私はこれらの問題のどこかで分析を行い、あなたと同様の結果を出しました。

@mburszley分析していただきありがとうございます。 昨年得られた結果を確認するために、別の方法（ast vs regex）を使用したかったのです。

私はあなたを聞きます、 @ mburszley 、しかし再：

委員会はただ「したくない」と言っているだけです

これが本当に_フィアット_の決定である場合（実際の使用状況の分析に基づいていないもの）、特に_stated_の理由がそのような分析の根拠であったことを考えると、コミュニティ全体にとって良い兆候ではありません。

したがって、委員会に、決定の基礎となった実際の使用状況分析を示す機会を与えるか、分析が不十分であることを認識して決定を再検討する機会を与える必要があります。

https://github.com/PowerShell/PowerShell/issues/11379#issuecomment-566756120での私の提案はどうですか？

$obj?.Method() <var i="12">Method</var>()がデフォルトで$<var i="9">obj</var> ?. <var i="12">Method</var>()し、 $<var i="14">obj?</var> .のみフォールバックするようにすることをお勧めします<var i="17">Method</var>() 、 $<var i="19">obj</var>がスコープに存在しないが、 $<var i="21">obj?</var>は存在し、 #requires ‑Versionはv7 +ではない場合。

下位互換性の懸念のほとんどに対処できると思います。

@ThomasNieto

@ mklement0は正しいですが、 ?を使用している変数のうち、62％が最後にそれを使用していることを意味しました。

ここのコメントに示されている結果から、 ?使用するすべての変数が最後にそれを使用しているようです。 したがって、重大な変更を加えないという提案。

{..}の要件が削除された場合でも、スクリプトは解析されますが、セマンティクスは異なります。これは、私の意見では非常に危険です。

確かに...しかし、分析によると、文字通りほとんど誰もそれらを使用していません。

他の重大な変更と同じように、発表し、しばらくの間実験的な機能として導入し、文書化して安定させることができます。

識別子文字としての?が実際にリモートでかなりの数のケースで使用されていない場合、難解な構文を推奨する理由はありません。

{..}の要件が削除された場合でも、スクリプトは解析されますが、セマンティクスは異なります。これは、私の意見では非常に危険です。

また、C / C ++ / C＃のように?.を使用していて、何も悪いことを示さずに間違った結果が得られることを心配していませんか？ 例えば：

PS> $res = "My length is 15"
PS> $res?.Length
0

確かに、strict-modeはこれを見つけますが、多くの人がstrictmodeを使用していることを私は知りません。 したがって、ごくわずかな割合のスクリプトが破損するのを防ぐために、 ?.を使用して失敗する多くの人々を設定しているようです。 私はトレードオフに夢中ではありません。 とはいえ、ごく少数の人でも、人を壊さないようにしたいという気持ちは確かに理解しています。

おそらく、PowerShellにはEnable-ExperimentalFeatureと同等のEnable-PSFeatureが必要です。これは、実験状態ではなくなったが、デフォルトでオンに場合です。 この$?.GetType()ようなコードで実行されるスクリプトの場合、将来これが壊れ、代わりに${?}.GetType()を使用する必要があるという警告を発し始める可能性があります。 個々のスクリプトは、 #requires -version 7.1 -feature PSNullConditionalOperators機能を有効にすることができます。 そうすれば、PS 8がヒットするたびに、この機能がデフォルトで有効になる可能性があります。

@rkeithhillの例は、
PowerShellが今日どのように機能するかについて知っていることを少し忘れてください。 あなたが見るとき

PS> $res?.Length

_name、operator、name_のように見えます-もちろんそれはそうです。
どちらがより理にかなっています：_ "？" 演算子の一部です_、または_ "？" 名の一部です-element_？
これらの演算子が必要な場合（そして「PowerShellyではない」と思う場合）、誤って使用されるものと少量の破損のどちらかを選択します。

変数名に特定の[正当な]文字を使用するのは悪いスタイルだと言うために、psScriptAnalyzer_now_にルールを入れ始めます。

Enable-featureは好きではありません。 誰かがそれをスクリプトに入れて、使いたいものを機能させます。古いスクリプトは、新しいスクリプトの後に実行すると壊れます（ただし、残りの時間は機能します）。 Yが厳密モードをオンにし、Xがオフに依存しているため、スクリプトY_を実行した後に_サードパーティのスクリプトXが失敗するのを見てきました。 両方のスクリプトの作者は私の悪い本にあります。

変数名に特定の[正当な]文字を使用するのは悪いスタイルだと言うために、psScriptAnalyzerにルールを入れ始めます。

問題は次のとおりです。PowerShellが変数をトークン化する方法を変更すると、PSScriptAnalyzerでも変数の表示が異なります。 $res?ような変数がある場合は、次のようになります。

{
$res?.Length
}.Ast.EndBlock.Statements[0].PipelineElements[0].Expression.Expression.VariablePath.UserPath

あなたにあげる

res?

ただし、PowerShellの解析方法を7.2などで変更すると、次のようになります。

PSScriptAnalyzerは?認識できなくなりました。これは、変数名の一部ではなくなったためです（定義上、テストしようとしている変更であるため）。 これは、PSScriptAnalyzerがPowerShellモジュールであり、PowerShellに同梱されているものと同じパーサーを再利用するためです。 （そして、それを再実装しようとすると、それは完全に保守不可能であり、災害のレシピになります）。

これを回避するには、PSScriptAnalyzerを条件付きでコンパイルする（そしてまったく新しいアセンブリを出荷する）など、新しい7.2ロジックをテストして同じ診断を提供する方法があります。 しかし、その後、どこでも複雑さが増し（または、テストサーフェスが減り）、やや表面的なシナリオに対応できるようになりました。

さらに悪いことに、ASTに依存している他のすべてのツールには、PSScriptAnalyzerがそうであるとしても、この種の複雑さを維持する能力がありません。 ASTターゲティングツールを構築しているほとんどの人は、完全な正確さのためにPowerShellの個々のマイナーバージョンに対してコンパイルすることはありません。 特にどのバージョンでもエラーではないので、彼らはおそらくそのような小さな重大な変更についてさえ知らないでしょう。 これは、ある行動が静かに別の行動になる、変化を壊す最も陰湿な形態です。

これが基本的に、このようなパーサー/トークンライザーレベルの変更をより危険なものにしている理由です。 PSScriptAnalyzerでさえ、正しくサービスを提供するために後方に曲がる必要があります。つまり、このような厄介な変更と比較検討する必要があります。

@rjmholt 、このような変更が_原則的に_どれほどトリッキーであるかは誰もが理解できると思いますが、この特定のケースでは_実際には_問題ではなく、PSSAルールも必要ないと思います。

• @ThomasNietoの分析によると、コーパスがそこにあるすべてのPowerShellコードを代表していると思われる場合、名前が? _で終わる変数は事実上誰も使用していません。

• 私が推測すると、ほとんどの人はそのような変数名を使用することさえ_考えません_。なぜなら、彼らはそれらが機能することを期待しないからです（私を含む）、そしておそらく自動$?という例外に気付かないでしょうbashなどのPOSIX互換シェルでも同様に例外です）。

  • 実際、 @ ThomasNietoの分析を8ファイルの中で次のことがわかります。
    
    
    
    • 5は_falsepositives_のみが含まれます。つまり、変数は"Are you sure you want to kill $vParam?"などの_strings_内で使用されます-実際、これらの使用は_壊れた_であり、スクリプトの作成者が?を期待していなかったことを示しています変数名の一部。
    
    
    • これらのファイルの2は公開されなくなりました。
    
    
    • それらのうちの_1_のみが、 ? -$key1? ）として誠実に使用しているため、余談ですが、メンバーアクセス演算子とは_結合されていません_ 、 . / cc @ stevenayers。
    
    

上記に基づいて、これは教科書のバケット3：ありそうもない灰色の領域の変更として私を襲います。したがって、これは_許容可能_です-そしてこの変更の_利点_は説得力を持って議論されていると思います。

行動の変化を（理論的根拠とともに）_文書化_するだけで十分です。

もちろん：

1. これは、（a）分析が正しいこと、および（b）公開されているコーパスが代表的であることを前提としています。

2. 「疑問符で終わる変数名がかなり使用されていた」という委員会の主張とはまったく相容れません（もちろん、そのような変数名が{...}囲まれていない場合にのみ問題になります。

1.が真である（2.をサポートするものは何も聞いていない）という仮定に基づいて進めると、2つの選択肢があります。

• {...}囲まれていない限り（ $?除いて）、バンドエイドを取り除いて、変数名の?を単純に禁止します-これは消えていく小さなものを壊します現在それに依存しているスクリプトの割合。

  • つまり、 $key1?ように、その後に.も、別の? （ $key1??'else' ）も、3項式（ $key1?1:0 ）も続きません。 _parsererror_が発生します。
    
    
    
    • null合体演算子と三項演算子の例が示すように、これらもこの変更の恩恵を受けます-現在、_スペース_- $key1 ?1:0 / $key1 ??'else' -または{...} - ${key1}?1:0 / ${key1}??'else'
    
    
  • _expandable strings_内では、 ?は（ {...}囲まれていない）変数名の一部とは見なされなくなるため、実際には、 "Are you sure you want to kill $vParam?"などの文字列を誤って使用した既存のスクリプトを_修正_します。

• 既存のスクリプトのごくわずかな部分を壊さないようにする必要があると本当に感じた場合は、@ ExE-Bossによって提案されたロジックを検討することはできますが、実装の複雑さは言うまでもなく、この概念の複雑さを導入したいとは思いません（私は本当に話すことはできません）。

@ SteveL-MSFT

9月のコミュニティコール（https://aka.ms/PSCommunityCall;この記事の執筆時点では、9月のコールの録音はそこに投稿されていませんが、https：//aka.ms/JoinPSCallからアクセスできます。次の電話まで）、46：00から、 https ： @ThomasNietoの提案に基づいています。

（レコーディングの関連部分への直接リンクを提供したいと思っていましたが、YouTubeに投稿され、https：//aka.ms/PSCommunityCallにリンクされるまで待つ必要があります。）

録音でのあなたの発言に基づいて：

• これを再検討する意思を示した場合は、この問題を再度開いて、 Review - Committeeタグを付け直してください。

• 変数名を中括弧で囲むことは既存の機能であり、この場合は_美的_理由で変数名を使用する必要があることに反対しているというあなたの意見については、次のようになります。

  • ここにいる誰もが、変数名を明確にするために{...}でき、場合によっては使用しなければならないことに気付いていないと思います。
  • また、それは_美学_についてではなく、主に_この場合は{...}を使用する必要がないため、_静かに失敗する_方法で_期待される動作が得られない_ことです。 二次的な懸念は、入力の不便です。

GitHub

PowerShell / PowerShell-RFC

PowerShellエコシステムの設計変更と改善に関するコミュニティフィードバックのRFC（Request for Comments）ドキュメント-PowerShell / PowerShell-RFC

Microsoft Teams

会話に参加する

この問題（現在は無期限に閉じた状態になっているように見えます）がひび割れに陥るのではないかと心配しているので、再訪するためのリマインダーとして＃14025を開きました。興味のある方は、ぜひご支援ください。