Powershell: 提案：null合体、null条件付きアクセス（nullソーキング）、null条件付き割り当てを実装する

@ mklement02番目のサンプルは「？」なしで設計上機能しているようです。
たぶんname()変更しますか？

@iSazonov ：良い点ですが、 Set-StrictMode -Version 2以上が有効でない限り、 ?なしでのみ機能します-それを明確にするために最初の投稿を更新しました。

シンタックスシュガーは、PowerShellが他の言語で利用できるものだと思います。 提案に+1します。

他の言語からの次のサンプルを検討してください。

a="${b:-$c}"
a = b || c;
a = b or c
a := b ? c
a = b ? b : c;

でも

a = b if b else c

よりも良い

if (b) { a = b } else { a = c }

多くの場合、さらに詳細に説明する必要があります

a =（if（b -ne $ null）{b} else {c}）

すべての汚れや恥ずかしさを感じさせます。

回避策として、今日これを行っていることに気づきました。

`` `powershell
$ word =（$ null、 "two"、 "three"）。Where（{$ _ -ne $ null}、 "First"）
「」

私は同様のパターンを使用します：

$word = ($null, "two", "three" -ne $null)[0]

@kfsone例$a=(if ($b -ne $null) { $b } else { $c })小さなエラーがあります。 $a=$(if ($b -ne $null) { $b } else { $c }) $( )である必要がありますが、 $a=$(if ($b -ne $null) { $b } else { $c })のみ$( )た。v2以降、次の操作を実行できます。

$a = if ($b) { $b } else { $c }

@bgshacklett $word=($null,'two')[$null -ne 'three']という意味ではありませんか？

これが6.1から6.2、そして「Future」に変わったのは少し残念です。

@ TheIncorrigible1いいえ、上記で追加したものをコピーして貼り付けると、 $wordの値が「2」に設定されていることがわかります。 私が最初にパターンを見たこのStackOverflowの回答には、より詳細な情報があります。
https://stackoverflow.com/a/17647824/180813

パーレスクなハックアラウンドは、RIPE-DBユーザーまたは組織のレコードを登録および/または照会するシバンを書いた20年前の私にアピールしますが、PowerShellに期待しているのは、同僚にその言語を使用するように促すものです。それらに恐れを植え付けるのではなく。

私のリトマス試験はこれです：新年の朝の午前3時にタブレットでこれを読みたいと思います。電話のCEOが私に何百万ドルも失っていると叫びながら、二日酔いをしました。

（余談ですが、これは私がFacebookで働き、緊急の迅速なリークから戻って、2分でオランダの人口よりも多くの人々が空になったと言われるまで、実際の経験の大まかな誇張にすぎませんでしたニュースフィード。それは私のコードではなく、間違いは、非常に特殊なテンプレートの場合のc ++標準でのreturnxとreturn（x）のセマンティクスのわずかな変更でした。「このコードを2分で読みたいですか。締め切り、満腹、そしてオランダ人の猫の写真を肩にかけているすべての詰まりの運命は、それほどクールに聞こえませんでした）

うん。 PSには、ピンチや1回限りの速記が必要な場合に最適な巧妙なトリックがいくつかあります。

保守可能なコードの場合、理想的には、C＃のような明示的なnull合体演算子が必要です。 私にとっての主な問題は、それらに何を使用するかということです。 ?はすでにWhere-Objectエイリアスされています（これを消去したいのですが、非常に一般的に使用されています）。 %はForEach-Objectエイリアスされますが、モジュラス演算を妨げることはないため、理論的には、少なくとも? null合体演算子にすることも可能です。罰金; Where-Objectが実際には有効ではない式では、そのように解釈されるだけです。

@ vexx32 ：

_expression_モードについて話しているので、少なくとも_syntactically_ ??は問題ないはずですが、 ?は、コマンド[エイリアス]として、_argument_モードでのみ認識されます。
シンボルの再利用が混乱を引き起こすかどうかはわかりませんが、シンボルがさまざまなコンテキストで二重の義務を果たすのは初めてではありません。

驚いたことに、PowerShellでは現在変数名の非頭文字として?が許可されているため、nullソーキングに?.と?[]を使用することは、技術的には重大な変更になります。

PS> $foo? = @{ bar = 1 }; $foo?.bar   # !! $foo? is a legal variable name
1

ただし、これがバケット3：グレーエリアの変更の

誰かが使っているのを見たことがないとは言えませんか？ 変数名で...誤読される可能性があるので、私もそうしません。 しかし、ええ、うまくいけば、それは完全に使用できるはずです。

これを提示するのは少し遅いと思いますが、Bashはパラメーター置換機能（ https://www.tldp.org/LDP/abs/html/parameter-substitution.html ）でこれ（およびその他のいくつかのケース）を処理しました

それを使ってできることの数が非常に多いため、学ぶのはクマかもしれませんが、それは信じられないほど強力です。 PowerShellが変数で中括弧を使用する方法のため、この正確な表記を使用することは不可能であり、言語の一般的な感覚に必ずしも適合するとは限らないことを理解していますが、これは有用なデータポイントのようです。

@bgshacklett ：

はい、パラメータの置換は強力ですが、残念ながら、それは_learn_だけでなく、_remember_にとっても負担になります。

そのため、Bashの_機能_はしばしば興味深いものですが、それらの_構文形式_はしばしば難解で、覚えにくく、PowerShellには適していません。

_Brace expansion_（例えば、 a{1,2,3}でbashに拡大a1 a2 a3 ）表現私はPowerShellで見るのが大好き、しかし、PowerShellの-適切なと思い興味深い機能の例です。構文-＃4286を参照

同意します。 この問題が正確な解決策ではなく、他の場所でどのように解決されたかの例として、私はそれを取り上げました。

考慮すべきもう1つの演算子があります。

$x ?= 12

設定されていない（存在しない）場合、 $x設定されます。 これは「初期化パターン」の一部であり、従来の言語では一般的ではありませんが、シェルやツールの作成などの（動的スコープの）言語では、ユーザーが指定していない場合にデフォルトを設定するスクリプトを使用するのが一般的です。 。 （実際、パラメーター初期化子はかなり普及しています。）

これをプロパティに拡張します。

$obj.SomeProperty ?= 13

オブジェクトが存在しない場合は、オブジェクトにメモプロパティSomePropertyを追加して初期化します。

そして-楽しみのために- -orを使用して変数を初期化するもう1つのバリエーション：

$x -or ($x = 3.14) > $null

$x ?= 12は素晴らしいアイデアのように聞こえます。

我々はおそらくLHSはない_exist_んが、また、それ_doesが存在する場合は発生した場合だけでなく、contain_するには、これらの演算子のすべてを適用すべきであると私に起こった$null （と[System.Management.Automation.Internal.AutomationNull]::Value同じように扱わ$nullこのコンテキストでは

ノートプロパティSomePropertyを追加して初期化します

その意味で、 $obj.SomeProperty ?= 13は、 .SomePropertyが存在し、 $nullが含まれている場合にのみ意味があります。これは、通常の割り当てでも暗黙的にプロパティを作成できないためです（対照的に、_hasthables_の場合暗黙的なエントリの作成は理にかなっています）。

説明するすべてのオペレーターは、LHSを厳密モードの存在チェックから免除する必要があります。

私はstrictmodeが存在しないプロパティにアクセスするからあなたを停止する理由の背後にある意図/推論に疑問を抱いています。 $x.pretndようなタイプミスをキャッチする意図はありますか？ assert(x != null)ような仮定をチェックする意図はありますか？ コード内で誤って$nullさらに伝播するのをブロックする意図はありますか？

nullソーキング（？。）は、$ nullを簡潔に無視するという明示的な意図を示すのに役立ちます。

それは、 .すでに非厳密モードで信号を送るものではありませんか？ 厳密にしたかった場合は、最初に.Name存在するかどうかを確認できます。最初に確認しないことで、確認は重要ではないという明示的な意図をすでに示しています。

StrictModeに、存在しないプロパティへのアクセスと$null返送が禁止されている目的がある場合、同じ理由が?.に適用されることはなく、同じ理由で同じ例外がスローされます。 。 そうでない場合は、なぜですか？

null合体を使用すると、次のように記述できます。

$result = Invoke-RestMethod -Uri 'https://example.org/api/test'
$test = $result?.Name

「 .ように動作し、strictmodeを使用している人に例外をスローしない」ため、すべてのプロパティ参照に常に?.を使用することがすぐに推奨または慣用的になりますか？

たとえば、スクリプトの先頭に宣言# StrictMode SkipMemberExistenceCheckを設定したり、 unstrict codeブロックを示すためのエスケープハッチング属性を設定したりできるように、変数設定を使用して構成可能なstrictmodeが必要です。一般的に？ [欲求は簡潔なC＃スタイルの構文だと思いますが、私が何を意味するかはご存知でしょう]

考えてくれてありがとう、@ HumanEquivalentUnit。

$x.pretndようなタイプミスをキャッチする意図はありますか？

設計意図について話すことはできませんが、それは私にとって理にかなっています- Set-StrictMode -Version 1が_variables_（のみ）に対して行うことと類似しています。

変数の場合、それは値がたまたま$nullであるかどうかではなく、それらの_existence_に関するものであり、プロパティの存在のチェックは同じパターンに従います。

静的に型付けされたコンパイル言語が_コンパイル時に_報告するエラーを見つけるのに最も近い動的スクリプト言語だと思います。

それは何ではありません。 信号はすでに非厳密モードになっていますか？ 厳密にしたかった場合は、最初に.Nameが存在するかどうかを確認できます。

はい。ただし、非厳密モードでは、前述の存在チェックを省略します。手動でのテストは明らかに非常に面倒であり、組み込み機能よりも常に低速です。

最初にチェックしないことで、チェックは重要ではないという明確な意図をすでに示しています。

重要なのは、 Set-StrictMode -Version 2以上の場合、次のようになるということです。

• _デフォルトで_メンバーの存在チェックの利点
• オプトアウトするオプション、_オンデマンド、簡潔に_ .?

スクリプトの先頭に宣言# StrictMode SkipMemberExistenceCheckを設定するか、 unstrict codeブロックを一般的に示すためのエスケープハッチ属性を設定できます。

関連： Set-StrictModeの現在の動的スコープには問題があります。 _lexical_ strictモードを実装するための@lzybkrのRFCドラフトを参照してください。 https://github.com/PowerShell/PowerShell-RFC/blob/master/1-Draft/RFC0003-Lexical-Strict-Mode.md

デフォルトでメンバーの存在チェックの利点

PSには、メンバーチェックを実行するコードが含まれており、メンバーが存在しない場合は$ nullを返します。 これはデフォルトの利点であり、必要に応じて$x.psobject.properties...て独自のメンバー存在テストを作成することでも回避できます。 StrictModeはその利点を取り除き、存在テストを作成しなければならないという?.は、 .常に実行することを取得するための簡潔な回避策を提供します。 また、メンバーが存在することが重要な場合でも、それを個別にコーディングする必要があります。

しかし、これは私にメソッド呼び出しについて何を尋ねさせます：

$x.pretend     -> $null
$x.pretend()   -> Exception MethodNotFound
$x?.pretend  -> $null
$x?.pretend()   -> ____ what goes here? $null?

set-strictmode -version 2
$x.pretend -> Exception PropertyNotFoundStrict
$x.pretend()  -> Exception MethodNotFound
$x?.pretend  -> $null
$x?.pretend()   -> ____  ?

つまり、 ?.は、非strictmodeでのプロパティルックアップの.と同じように動作しますが、non-strictmodeでのメソッド呼び出しの.とは動​​作が異なり、微妙な違いがあります。ドロップインの交換。 つまり、 ?.を使用すると、メソッドが呼び出されたかどうか、または何も起こらなかったかどうかを判断する方法がまったくないということですか？ プロパティはgetterメソッドでサポートできますが、DotNetでは、getterが内部状態を変更しないのが慣例であると思いますが、メソッド呼び出しが状態を変更するのは通常のことです。 ?.を使用すると、オブジェクトの状態を変更したかどうかわかりませんか？

??が左側の式から直接PropertyNotFoundExceptionとMethodNotFound Exceptionsを処理できるようにし（ただし、メソッド内で発生する他のExceptionsは処理できない）、$を処理することで、目的のメリットを得ることができるかどうか疑問に思います。 nullであり、 ?.はまったくありません。 例えば

$varThatMayBeNull ?? $fallbackValue # null-coalescing
#
$varThatMayBeNull.Name ?? $fallbackvalue    # catching PropertyNotFoundStrict exception
$varThatMayBeNull.Name ??  # default fallback is $null
$varThatMayBeNull.Method() ??  # catching MethodNotFound Exception

# and potentially addressing the index case too
$varThatMayBeNull.first.second[3].Method() ??  # catching MethodNotFound Exception, or index not found Exception

そして、 ?.がメンバーを呼び出したり、プロパティにアクセスしたりする代わりに、メンバーが存在するかどうかを尋ねる簡潔な方法であり、[bool]を返します。

??と?.の同じ構文の追加により、より多くの状況を、混乱の少ない重複で処理できます。

StrictModeはその利点を取り除き、存在テストを作成する必要があるという障害を残します

ある人の障害は別の人の利益です：
それはすべて、_デフォルトで_何をしたいかによって異なります。

• コードに_typos_がないと確信している場合は、必ず_default_の動作（厳密モードOFF）を利用してください。 .? （_ property_アクセスの場合-を参照）は必要ありません。次のコメントは_methodcalls_と_indexing_）です。

  • _personal_注：_variable_名のタイプミスを避けるためにSet-StrictMode -Version 1を使用する傾向がありますが、主に＃2798（これは独立したバグです）が原因で、 -Version 2以上が煩わしいと感じています。この提案）。

• （a）プロパティ名のつづりを間違えていないこと、および/または（b）コードが意図した以外のデータ型で誤って操作されていないことを確認したい場合は、strictモードをバージョン2以降に設定してください。

  • 確かに、その_現在_は、これらのチェックを_オンデマンド_で_オプトアウト_するのを面倒にします。
  • これがまさに、ヌル条件付きアクセスの導入がここで提案されている理由です。オンデマンドでオプトアウトするのを_簡単_にするためです。

メンバーの存在を明示的にテストすることは、実際には別のユースケースであり、有効な厳密モードに関係なく必要になる可能性があります。

OPがカバーしていない_メソッド呼び出し_について：

_メソッド呼び出し_（例： $varThatMayBeNull.Method() ）と_indexing_（例： $varThatMayBeNull[$index] ）は、厳密モードがオフまたはバージョン1であっても、両方のケースが現在_常に_エラーを引き起こす場合にメリットがある2つのケースです。アクセスされている値は$nullです。

構文は、メソッドのプロパティの場合（ $varThatMayBeNull?.Method() ）と同じであり、インデックス作成の場合（ $varThatMayBeNull?[$index]はC＃の場合と同様です。

_Update_：インデックス付けには2番目の側面があります。つまり、変数がnull以外であるが、指定されたインデックスの要素が存在しない場合（たとえば、 $arr = 0,1; $arr[2] ）。 ストリクトモードバージョン2以下では、これは$nullと評価されますが、バージョン3以降ではエラーが発生するため、このエラーをオプトアウトできると便利です。 ただし、この場合の構文には課題があります。現在、おそらく厄介な[...?]提案している更新されたOPを参照してください。

そして、はい、私はそのようなアクセスをデフォルトで$nullします-メソッドの場合でも-繰り返しますが、アクセスされているオブジェクトが$nullまたはそのような配列要素が存在しない場合。

C＃には、第2の意味でnull条件付きインデックスがないことに注意してください。

提案している方法とはまったく異なり、null条件付きのインデックスが作成されます。 C＃は（少なくとも...） array?[0]を許可します。これは、通常の「インデックスをnull配列/コレクションに入れる」問題をバイパスしてnullを返すだけです。

しかし、ええ、私はこれが良い考えであることに同意します。 これにより、例外処理を行う手間が省け、コードが非常に明確で簡潔になります。

@ vexx32 、つまりnull条件付きインデックスの_one_アスペクト： array array?[0]がnull場合、インデックス操作は無視されます-あなたが述べているように、C＃にもそれがあります。

私があった（アップデート：_also_）ヌル条件インデキシングの_other_態様の話：場合arrayでarray?[0] _not_あるnullそれはインデックスで_The要素であります0 _存在しません。

私の知る限り、C＃で無視できないのは後者ですが、それでも役立つと思います。

これらの2つの側面に異なる名前を付けるための用語を考えることができますか？

別のJavaScriptの問題のコードは、 $_.Description[0].Textから$_?.Description[0?]?.Textになりますが、これはきれいではないと思います。 そして、 ??がどのように動作するかについての他の提案は、主観的に優れた$_.Description[0].Text ??になり、実装が可能であれば、チェーン内の任意のルックアップポイントでの障害を一度に処理します。 、それでもデフォルトで何をしたいかを選択でき、 $nullだけに制限されるのではなく、自由に別のフォールバックを使用できます。

余談ですが、この?.構文には、静的プロパティとメソッドの類似物、つまり$t = [int]; $t::MaxValu; $t::Pars("1") ?::ますか？それは?:または?::ますか？

複数のインデックスが指定された配列インデックスの望ましい動作は何でしょうか？ $array[0,4?,1,2]それぞれが失敗することを許可される場合、または$array[0,4,1,2?]で、ロット全体のみが成功または失敗することが許可されますか？

少なくとも概念的には、分離する価値のある側面を混同していることに気付いたので、最初に一歩後退する必要があります。

• _Null-value_-C＃の場合のように、条件付きメンバーまたはインデックスアクセス：

  • アクセスされている値が$null場合、そのメンバーにアクセスしたり、そのメンバーにインデックスを付けたりする試みを無視して、 $nullと評価します。

• _Member-existence_-PowerShellに固有の条件付きメンバーまたはインデックスアクセス：

  • アクセスされている値が_non- $null _の場合、存在しない_members_（プロパティ、メソッド呼び出し、インデックス付け）にアクセスしようとする試みは無視してください。

注：簡潔にするために、ここでは_member_をやや大まかに使用して、ドット表記ではなく_indexing_でアクセスされるコレクションであるオブジェクトの_elements_も包含しています。

コードにタイプミスがないことを確信している場合は、必ずデフォルトの動作（厳密モードをオフ）を利用してください。そうすれば、。？は必要ありません。 （プロパティアクセス用

@ mklement0 「ある人が自分のコードを改善するためにstrictモードを使用している」という観点から話していると思いますが、「他の誰かが私のコードをstrictmodeで実行できるのですが、どのような変更を加えると、私のコードも機能するようになりますか？ 「そしてそれは私を別の推論に導きます。 ?.を使用すると、 .代わりに使用して、コードをstrictmodeでも機能させるので、どこでも習慣的に使用したほうがよいでしょう。 私は何も失うことなく、互換性を獲得します。 より多くの場合に「機能する」ため、すべてのPowerShellコードがそのように醜くなるのではないかと心配しています。

ただし、これはドロップイン置換ではありません。これは、非strictmodeで失敗したメソッド呼び出しルックアップを無音にし、strictmodeで失敗したプロパティルックアップを無音にするためです。これは、非常に一般的な操作であるメンバールックアップに厄介なニュアンスを追加します。 ボイラープレートを簡単にすることで、strictmodeチェックの恩恵を受けたい人には役立ちません。 それが追加する複雑さのために、それは十分な状況で十分な人々を助けません。 そして、コードの互換性を高めるのは便利すぎます。「コードを望まない場合は無視する」というのは、コードを寄せ付けないほど強力ではないと思います。

PowerShellは、自動変数の設定や、例外がスローされて舞台裏で沈黙する前例があるなど、C＃ではできないことを実行できます。 メンバーの検索をまったく複雑にしない、より良いアプローチが必要ですが、厳密モードの安全チェックの定型文を簡素化して、チェックを使用したい人がより簡単に生活し、チェックに悩まされた人もより簡単に生活できるようにします。

@HumanEquivalentUnitどうやってこれらのものを沈黙させるのですか？ 代わりに、事前に大量の例外処理とnullチェックを作成する必要があります。

$prop = $item?.Method().PropIwant ?? 'PropActionFailed'

v。

$prop = if ($null -ne $item) {
    $propIwant= $item.Method().PropIwant
    if ($null -eq $propIwant) {
        'PropActionFailed'
    }
    else {
        $propIwant
    }
}

そして、このケースは珍しいことではありません。 または、 $ErrorActionPreference = 'Stop'をスローし、全体をtry/catchでラップして、悪いパターンであるnullチェックを単純化します（例外駆動型ロジック）。

また、これは言語の未来であり、5.1に戻って状況を変えるわけではありません。 より多くのアダプターが必要な場合は、コードを読みやすくする必要があります。この提案はそうだと思います。

@ mklement0 「_自分のコードを改善するために厳密モードを使用している人_」という観点から話し合っていると思います。「_他の誰かが厳密モードでコードを実行できます。どのような変更を加えると、コードが機能するようになりますか？」 _ "

「set-euopipefail」（bash strictモード）に相当するものについて話しているのですか？

a-変数ルックアップへの制限（メンバールックアップの単純なnullチェックが悪いことだと思う理由はわかりませんが、実際のメンバールックアップはif (result is null)よりもはるかに高価です）
b-スコープ/コードブロックで[Strict]を使用して、パーサーにそれらをそのように扱うように指示します。
c-厳密性はスコープに基づいています。厳密とマークされていないコードは厳密ではありません。

使用すると失敗する厳密なコードを書いた場合、私たちの1人が間違いを犯しました。 テストしたことのないコードで欠落している変数を参照したか、関数に渡されない変数の存在に依存する不適切に設計されたAPIを誤解し、入力されると予想される変数を入力できませんでした。 。

# Their code
Function Log($Message) { Write-Host $Massege }  # not strict

# My code
[Strict]
Function DebugMsg
{
  Param([String] $Message)
  if ($DEBUG) { Log Host $Message }
}

# Your code
DebugMsg "Hello"  # you didn't define DEBUG, and by saying strict I expressed a contract whereby the variable MUST be defined.

「ログ」機能は厳密にマークされていないため、タイプミスについて文句を言うことはありません。

🤔おっしゃるとおり、 [Strict()]属性は、スコープが制限された方法でstrictモードを実装するための_素晴らしい_方法になります。 これは、厳密モードの問題に関する他の問題スレッドで言及する必要があります。それを掘り下げて、ここにリンクします...

@ TheIncorrigible1 「これらのことをどのように沈黙させますか？ 」非厳密モードでは$null.xは沈黙し、 $null.x()は例外です。 説明したように?.では、 $null?.xは無音で、 $null?.x()は無音です。

したがって、例外をスローするstrictモードを除いて、C＃の?.のように機能する.あります。 次に、C＃の?.のように厳密モードで動作する?.があり、PowerShellの.は非厳密モードで動作しますが、PowerShellの.とは動​​作が異なります。メソッド呼び出しの非厳密モードでは?.が明らかに優れていて、これらのシナリオの多くでより役立つ組み合わせ）。

代わりに、事前に大量の例外処理とnullチェックを作成する必要があります： $prop = $item?.Method().PropIwant ?? 'PropActionFailed'

メソッド呼び出しがスローされるか、$ nullが返され、PropIWantが欠落している可能性がありますが、それでも次のように記述する必要があります。

$prop = try {
    $item?.Method()?.PropIwant ?? 'PropActionFailed'  
} catch [someMethodException] {
    'PropActionFailed'
}

対私の提案した?? （ビルドが可能だった場合）、および?.の必要はなく、気になるのが「成功かどうか」だけの場合のメソッド例外の考えられるケースをカバーしています。詳細なエラー処理はありません。

$prop = $item.Method().PropIWant ?? 'AnythingFailed'

より多くのアダプターが必要な場合は、コードを読みやすくする必要があります。これは、この提案が行うと思います。

PowerShellで.と入力する頻度はどれくらいですか。 .と?.の違いを新しいユーザーに説明し、 .永遠に入力するたびに違いを考慮する必要があることをどのくらいの頻度で説明し

「ああ、どうしてそんなことが起こったの？」 「C＃では.がメンバーの欠落に対して例外をスローしたので、彼らは?.を発明しましたが、そうではありませんでした。それは素晴らしいことでした。デフォルトで、PowerShellで.はスローしません。次に、 . C＃のように動作させ、そのコンテキストでのみスローするstrict-modeを発明しましたが、メンバーを手動でチェックする方法は非常に面倒で面倒で、誰も入力したくありませんでした。その問題に正面から取り組み、strictmodeの恩恵を受けるためにそれをより便利にする代わりに、彼らはそれをかわし、代わりにC＃の?.使って、あなたが要求した厳格さから卑劣な方法を得ました。そして、あなたはまだメンバーの存在テストを持っておらず、strictmodeの恩恵はまだ言葉で面倒ですが、少なくとも「strictmode」には「normalmode」エスケープハッチがあるので、それに苦しむ必要はありません今」。 いや。

使用すると失敗する厳密なコードを書いた場合、私たちの1人が間違いを犯しました。

メンバールックアップの単純なnullチェックが悪いことだと思う理由はわかりませんが、実際のメンバールックアップは（結果がnull）の場合よりもはるかにコストがかかります。

それは悪いことではないと思います。PSnon-strictmodeはすでにそれを行っています。これは、提案された?.望ましい代替手段になると思います。これは非常に異なり、より多くの状況で役立ちます。

ただし、PSではC＃ではできないことを実行できることに注意してください。

(1..3)[1kb..100kb]

非strictmodeでも例外はありません。 数値を変更して、所要時間を確認してください。 パフォーマンスと、任意のオブジェクトにインデックスを付けるために舞台裏でどのように機能する必要があるかを判断すると、便宜上、実際には最大100,000の例外が発生して沈黙しているようです。 PSは、常に「できるだけ速くする必要があり、ユーザーに不便をかける」という選択をするわけではありません。私はそれが好きです。

@HumanEquivalentUnitキャリアで使用することのないすべての言語には多くの機能があり、スタイルが気に入らない場合は問題ありません。これらの機能を使用する必要はありません。 なぜ厳密モードをオフにしているのかわかりません。 これはスクリプトでの良い習慣なので、言語に問題を飲み込ませるのではなく、意識的に問題に対処します（そして、本質的に、どこにでも暗黙の空のキャッチブロックがあります）。 繰り返しになりますが、この機能を使用しないことを歓迎します（たとえば、 Out-Default使用したことはありません）。

また、演算子は?ではなく?.です。 インデックスアクセスでも機能します。

さらなる議論のための基礎を築くために続行するには、私は既存の厳格なモードが（用語が導入された以上）：

以下の列はSet-StrictMode設定を表し、列の値は次のことを示しています。

• 👍...許可
• 🚫...禁止（ステートメント終了エラーが発生します）

余談ですが、エラーが_script_-terminationではなく_statement-_のみであるという事実は、PowerShellのエラー処理に関するより大きな議論に関連しています-https ：//github.com/PowerShell/PowerShell-Docs/issues/1583を参照して

• _Null-value_-条件付きアクセス- $obj _itself_は$nullです：

構築| -オフ| -バージョン1 | -バージョン2 | -バージョン3以降
---------- | ---- | ---------- | ---------- | ------------
$ obj | 👍| 🚫| 🚫| 🚫
$ obj.Prop | 👍| 👍| 🚫| 🚫
$ obj [42] | 🚫| 🚫| 🚫| 🚫
$ obj.Method（）| 🚫| 🚫| 🚫| 🚫

-Offと-Version 1では、 $obj.Propが許可されているのに対し、 $obj[42]は許可されていないのは不思議です。

• _Member-existence_-条件付きアクセス- $objは$null以外ですが、アクセスされているメンバー/要素は存在しません：

構築| -オフ| -バージョン1 | -バージョン2 | -バージョン3以降
---------- | ---- | ---------- | ---------- | ------------
$ obj.Prop | 👍| 👍| 🚫| 🚫
$ obj [42]（インデックス可能）| 👍| 👍| 👍| 🚫
$ obj [42]（索引付け不可）| 👍| 👍| 🚫| 🚫
$ obj.Method（）| 🚫| 🚫| 🚫| 🚫

本質的にインデックス付け可能なオブジェクト（配列など）が-Version 2でも存在しない要素へのアクセスを許可するのに対し、スカラー（PowerShellがコレクションとの統合処理のためにインデックス作成機能を提供する）が許可しないのは不思議です。

StrictMode latestで実行し、存在する場合と存在しない場合があるプロパティにアクセスしようとする場合、 nullソーキング（

function Get-OptionalPropertyValue($object, [string] $propertyName) {
    if (-not ([bool] (Get-Member -InputObject $object -MemberType Properties -Name $propertyName))) {
        return $null
    }

    $object.$propertyName
}

$value = Get-OptionalPropertyValue $foo "bar" # if $foo.bar exists, $value will contain its data; else $value will be $null

あなたが_本当に_書くことができるはずのとき：

$value = $foo?.bar # if $foo.bar exists, $value will contain its data; else $value will be $null

みんな、あなたはこの提案からのみヌル条件付き得ることができる場合には、実装され、プロパティだけのために、それは多くの苦痛ので、非常に多くの人々を救うだろうしてください。

私はこれを調べ始め、いくつかの問題を見つけました。

??と?=考えてみましょう

$x ?= 1と$x ?? 1は簡単なようです。 ただし、これらは演算子であるため、 $x?=1と$x??1をサポートする必要があります。

これに伴う問題は、 $x?と$x??両方がPowerShellの変数名を検証することです。 明確にする唯一の方法は、 ${x}?=1と${x}??1です。

さらに、条件付きメンバーアクセス?.と?[]場合、 ${x}?.nameと${x}?[0]ます。
これらの場合、 $x ?.nameおよび$x ?[0]はサポートされません。

もう1つのオプションは、重大な変更を導入し、変数名に?をまったく許可しないことです。

どう思いますか？ @ mklement0

/ cc @rjmholt @ daxian-dbw @JamesWTruher

?が有効な変数名である理由を特に_好き_も理解もしていません。 $Safe?ような名前の扉が開かれます。これは、とにかく$IsSafe書くと、一般的にわかりやすく、扱いにくくなります。

変化はおそらく長い間続いていると思います。

それは$ Safeのような名前の扉を開きますか？ とにかく$ IsSafeと書くと、一般的にはより明確で扱いにくくなります

興味深いことに、私は反対の感情を表明しました。 これは古典的なScheme / Rubyの伝統です。

if ($questionMark?)
{
    Write-Host "That's silly!"
}

三項演算子にも同じ問題がありませんでした。解決策は、 ?で終わる変数を適切に処理するために、演算子の前後にスペースを必要とするか、変数名を中括弧で囲むこと

これらの演算子が導入されると、PowerShellは$x?[0]などの構文で?を演算子の一部として認識することを優先し、 ?終わる変数名を使用するユーザーが使用できるようになると思います。コレクションを格納するための${x?}?[0] 。 $x?.Nameと${x?}?.Name同上。

他のオプションは、重大な変更を導入し、許可しないことです。 変数名にはまったく含まれていません。

👍これはメジャーバージョンの変更（6から7）であることを考えると、ここで重大な変更を加える価値があると思います。 GitHubに、 ?で終わるPS変数のインスタンスがいくつあるかを確認するためのより良いコード検索があればいいのにと思います。 これはそれほど影響はないと思いますが、GitHubに対してそれを確認するのは良いことです。 PowerShellを使用して14年間、変数名に?を使用したことはありませんが、それは私だけかもしれません。 :-)

その船はずっと前に出航しており、今日のスクリプトで?で終わる変数が使用されているのを見ても驚かないでしょう。

この時点で、これらの新しい演算子に関して、変数名の一部としてではなく、演算子の一部として?解析を単純に優先する場合、 ?終わる変数名を使用する人々は必要になります。 {}またはスペース（スペースが許可されている場合）を使用して、これらの演算子でこれらの変数を使用します。

この文脈で「その船が出航した」という言葉を聞くのは奇妙です。 これは_メジャーバージョン_の変更です。 これがここで変わるのは不合理ではないと思います。

@rkeithhill私は個人的なものでそれを使用しましたが、変数名の一部として記号を使用することはプログラマーにとって非常に直感的ではないため、共同作業を行うことは不明確だと思いました（変数として絵文字を使用するのと同様）

「優先解析」を行う@KirkMunroは、バグの扉が開いているように聞こえます。

@ vexx32 ：これはメジャーバージョンの変更であるため、重大な変更を行うのは不合理ではありません。 ユーザーがで終わる変数を使用する可能性があるためしかし、このような破壊の変更のためのバーは非常に高いままにしてください、と私はこれが近いというバーを渡しに来ないと思います?うまく限り、彼らが使用して{}変数名を識別するための

?で終わるプロパティ名を付けることもできます。 現在、名前を引用符で囲まずにPowerShellでそのようなプロパティを表示しようとすると、パーサーエラーが発生します。

例えば：

PS C:\> $o = [pscustomobject]@{
    'DoesItBlend?' = $true
}
PS C:\> $o.DoesItBlend?
At line:1 char:15
+ $o.DoesItBlend?
+               ~
Unexpected token '?' in expression or statement.
+ CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : UnexpectedToken

PS C:\> $o.'DoesItBlend?'
True

今日は解析されないことに少し驚いていますが（なぜ解析されないのですか？）、それにもかかわらず、そのようなプロパティの場合は、名前を引用符で囲む必要があります。その場合、引用符の後に3項nullを付けることができます。 -スペースのない合体などの演算子。問題なく動作します。 この構文は${x?}?.nameに非常に似ていると思います。必要に応じて、このような変数/プロパティ名を使用できるというスタンスで問題ありませんが、このような名前では、3項またはnullを処理するために追加の構文または間隔が必要になる場合があります。 -*演算子。

@KirkMunro難解な変数名が必要な場合、今後、変数の境界を使用することを

PowerShell 7を使用している人は、すでに熱狂的であり、重大な変更に気付くでしょう。 そうでない人は、まだ<= v5.1を使用しており、長期間使用し続けます。 おそらくmsftがそれをWindows10から削除するまで（決して）。

@KirkMunroもちろんですが、標準の許容変数文字から削除しても、ユーザーが変数名として${Valid?}を実行することを妨げることはありません。 これらの演算子を使用する必要があるため、 ?変数名の一部と見なされる文字にするよりも、一貫性を持たせる方がよいと思います。

それはすでに壊滅的な変化になるでしょう、そして私は少なくともそれについて一貫していて、別のレベルの曖昧さを導入するよりもずっと行くことが最善だと思います。 🙂

@adityapatwardhan言語では、有効な変数文字として?を削除する方がよいと思います。 これにより、null-soak / -coalesce演算子と三項演算子の両方が使い慣れた構文で簡単に有効になり、スクリプトの作成プロセスに多くの人間工学が追加されます。

「優先解析」を行う@KirkMunroは、バグの扉が開いているように聞こえます。

@ TheIncorrigible1 ：適切に実装されていない場合、どのコードでもバグの可能性があります。 PowerShellが変数の境界で囲まれていない変数名を解析し、 ?文字に遭遇したときに、PowerShellが三項演算子またはnull- *演算子に遭遇するかどうかを識別するための、単純な1文字の先読みについて話しているだけです。 これは複雑ではなく、他のコード変更よりも多くのバグの扉を開くことはありません。

PowerShell 7を使用している人は、すでに熱狂的であり、重大な変更に気付くでしょう。 そうでない人は、まだ<= v5.1を使用しており、長期間使用し続けます。 おそらくmsftがそれをWindows10から削除するまで（決して）。

@ TheIncorrigible1 ：その声明の根拠/証拠は何ですか？ PowerShell 7はプレビュー段階にあるため、現在は愛好家のみが使用しています。 それは当然のことです。 ただし、プレビューを超えて、PowerShell 7以降が企業に必要な魅力的な機能を提供し、必要な機能をサポートしている場合は、それらのバージョンを使用します。 これは、PowerShell7がOSとともにインストールされる場合に特に当てはまります。 熱狂的なファンが関与する唯一のポイントは、PowerShell7がもたらすものに対するビジネス上のニーズがない組織にあります。

それはすでに壊滅的な変化になるでしょう、そして私は少なくともそれについて一貫していて、別のレベルの曖昧さを導入するよりもずっと行くことが最善だと思います。 🙂

@ vexx32それはそれを伸ばしています。 変数名に??がある場合、それは重大な変更になりますが、その可能性は、名前が単一の?終わる変数を持つよりもはるかに遠いです。 それ以外に、今日の標準の許容可能な可変文字ブレークスクリプトとして?をサポートしながら、null- *演算子を導入するにはどうすればよいでしょうか。

私の経験では、便利なもの（これはそう思われる）の変更を壊すことは、拒否されない場合がはるかに多く、それらを取り巻く議論/議論は、物事を劇的に行うプロセスを遅くするのに役立つだけです。物事が行き詰まったり、リリースに入るのを逃したりするポイントなど。重大な変更を提案する場合は、影響を評価してそのような変更を正当化できるようにするために証拠が必要になるため、スローダウンが必要になることがよくあります。 今日、その証拠を集めるのは難しいです。 私はこれを言っているのは、いつでも便利な破壊的な変更について議論するよりも、今すぐ機能を実行することを選択するからです。

変数名に?を使用することはありません。また、使用する人もいると思います。スクリプトで非常によく読み取ることができ、PowerShell 7のエントリに不要な障壁を設けると、採用が遅くなるだけです。特に、PowerShellを使用する多くの人が、重大な変更を処理することに慣れている開発者ではない場合はなおさらです。

とにかく、このプロセスを遅くすることは私の意図ではなく、むしろその逆です。 しかし、私は自分の考えと経験を共有したので、ここで画期的な変更を推進すべきかどうかについてはこれ以上コメントしません。

この不自然な例を考えてみましょう。

$ValueIsValid? = @( $true, $false, $false, $true )

$ValueIsValid?[0]
# old behaviour? gets `$true`
# new behaviour? gets nothing, because the `?[0]` is interpreted as a null-conditional access.

この動作は、提案された変更で_すでに_壊れます。 考えられるすべての例外と、 ?突然無効になったときと場所、およびそれがまだ有効である場所を一覧表示するために半ページの説明が必要な紛らわしい休憩よりも、一貫性のあるクリーンな休憩をお勧めします。

@KirkMunro PowerShell 7以降が企業に必要な魅力的な機能を提供し、必要な機能をサポートしている場合は、それらのバージョンを使用します。 これは、PowerShell7がOSとともにインストールされる場合に特に当てはまります。

数十万人の従業員を抱える数人のフォーチュン50で働いていたので、OSのデフォルトから離れることさえ困難でした（つまり、v5.xへの移行）。 Coreを採用している場所はまだありません。 相互互換性のためにPythonに移行したいだけです。 Windowsのオプション機能を有効にすることも、めったにありませんでした。

企業は、問題を解決するために新しいテクノロジーや言語バージョンを探すことについて、自分たちが持っているものと従業員の知識ベースを活用していると思います。 一部のユーザーは、v2に永遠にとどまり、Win10 / Server16コマンドレットに触れないことで完全に満足するでしょう。

これらすべてについての私のポイントは、これらの機能が真空状態にないということです。 言語をより人間工学的にすると、問題をより早く解決するためのツールに関心のある人々による採用が増えるでしょう。 （参照：C＃およびより多くの/より優れた言語機能による人気の高まり）

?終わる変数に関して-自動変数$のため、これは重大な重大な変更になる可能性があり

@lzybkrこれに対処するための最良のケースは、 $^と$$すでに存在するような特殊なケースだと思います。

@lzybkr @ TheIncorrigible1私が覚えている限り、これらの変数の$^ _ already_は有効な変数名ではありません。 トークナイザーには、標準の変数名の検索を開始する前に、これらすべてに特別なケースがあります。

ここでの唯一の解決策は、 ¿を使用することです。

$ silly？¿= 1

私はスティーブを知らない、私はこれについてのインテロバングの群衆の中にしっかりといる。

$silly?‽=1

@ lzybkr-私の知る限り、 $? $$と$^は特別な方法で扱われます。

https://github.com/PowerShell/PowerShell/blob/8b9f4124cea30cfcd52693cb21bcd8100d39a796/src/System.Management.Automation/engine/parser/tokenizer.cs#L3001 -L3004

要約すると、これらの4つのオプションがあります

• 大きな重大な変更-変数名に?を許可しません。
• 演算子として?.を優先します。 つまり、 ?終わる変数名は、 ${variablename}構文を使用する必要があります。 まだ壊滅的な変化。
• 古い動作を優先します。 これは、 ?.と?[]を使用することを意味し、 ${variablename}?.property使用する必要があります。 重大な変更はありませんが、新しい演算子の使用は不器用になります。
• 新しい演算子を実装しないでください。

私は個人的に、最初と最後のものを好みません。

これはメジャーバージョンの変更です。 これがここで変わるのは不合理ではないと思います。

重要な点は、メジャーバージョンが増分されて、Windows PowerShellを置き換える準備ができていることを示していることです。つまり、破損ではなく互換性を示しています。 元の発表から：

メジャーバージョンは、重大な重大な変更を行うことを意味するものではないことに注意してください。

オプション1と2は同じではありませんか？ または、変数の後にnull合体演算子または3項演算子がない場合でも、変数は?を使用できますか？

もしそうなら、私たちは多くのバックトラックなしでトークン化/解析ロジックを処理するのに多くの問題があるかもしれないと思います。 これにより、変数が?終わる場合、パフォーマンスが低下する可能性があります。

私が見ることができることから、オプション2が一般的な好みであるように思われることを考えると、ここで重大な変更を行うことに抵抗があることを私は本当に理解していません。 そうすることで、変数名を囲まないと使用できないシナリオを導入するだけで、変数名での?使用を積極的に阻止できます。

重大な変更が進むにつれて、これはかなり小さな変更だと思います。変数名で使用できるものとできないものの一貫性を中断することは、おそらく悪い選択肢だと思います。

これらのものには、ほとんどすべての状況に適用される明確なルールが必要です。 現在、これが当てはまります。 ここで水を濁らせ、行動を明確にすることを提案しています。 ?を含む変数名が、一部のシナリオで使用するのが難しいという理由だけで使用されなくなることを除いて、そこから良いものは何もわかりません-これは（事実上）オプション1に戻りますデフォルトでは、ほとんど...ですから、今休憩を取らず、あいまいな動作を避ける特別な理由はありません。

@ vexx321と2の間にはわずかな違いがあります。

＃1の場合、 ?を変数名で一緒に使用することは許可されていません。 これは、 $x? = 1 、 $x?? = 1 $x?x?x = 1が解析されないことを意味します。

＃2の場合、 $x? = 1は引き続き有効ですが、 $x?.nameは${x}?.nameと同等です。 これは、メンバーにアクセスしている最後に?付いている変数名のみを分割します。 したがって、 $x? = 1 、 $x?? = 1 $x?x?x = 1は引き続き有効です。

ええ、私はそこでオーバーヘッドをトークン化することについて少し心配するでしょう。 両方の可能性を実装し、同様の変数名をかなり頻繁に使用するスクリプトでいくつかのベンチマークを実行する価値があるかもしれません。

私の好みは間違いなくオプション1です...少なくとも私にとっては、1回限りの変更は、将来の方法で解析する方法の不整合に対処するよりもはるかに好ましいです。

もしそうなら、私たちは多くのバックトラックなしでトークン化/解析ロジックを処理するのに多くの問題があるかもしれないと思います。 これにより、変数が？で終わる場合にパフォーマンスが低下する可能性があります。

私はその可能性についてこの懸念を共有します。 ?を時々トークンの区切り文字として持つことは、私にはその言語のギザギザの線のように感じます。

もしそうなら、私たちは多くのバックトラックなしでトークン化/解析ロジックを処理するのに多くの問題があるかもしれないと思います。 これにより、変数が？で終わる場合にパフォーマンスが低下する可能性があります。

それはあなたがそれをどのように実装するかに依存します。 トークン化してからバックアップするアプローチではなく、先読みアプローチを採用する限り、問題はありません。 変数名に?れている場合は、次の文字を先読みし、次の文字に基づいて変数トークンをどのように「まとめる」かを決定できます。 これはそれほど問題ではなく、バックトラックを必要としたり、パフォーマンスが著しく低下したりすることはありません。

@ PowerShell / powershell-委員会は今日これをレビューしました、私たちはいくつかの考えを持っています：

• 何をするにしても、スクリプトのコーパスを分析して、変数名で?を使用する頻度を確認します。
• 私たちの中には、変数名に?を使用しているユーザーは、それほど上級者ではない可能性があるという仮説（他の人が検証したい）を持っています（この部屋で同意するので、私たちはそれを避けます。発生する可能性のある潜在的な問題の）。 一方、ここで説明する機能を使用する人は誰でも、もう少し複雑な構文（ ${foo}?.bar ）を理解できます。 したがって、これらの経験の浅いユーザーの変更を壊さないようにするため、ます。 （ただし、最初の箇条書きに従って検証します。）
• @ daxian-dbwは、スクリプターが$fooと${foo}使用法を混合しているときに、すべての変数参照を見つけにくくすることについて良い点を挙げました。 ただし、これはツール（VS Code PowerShell拡張機能など）で修正でき、Vimなどの@JamesWTruherなどのユーザーは、両方を検索構文と簡単に一致させることができることに

スクリプト作成者が$ fooと$ {foo}の使用法を混合している場合、すべての変数参照を見つけるのが難しくなります。

これは、ASTが中括弧を見たかどうかに基づいて変数名を区別するかどうかによって異なります。 PowerShell ASTを使用するツールは、ここでは中括弧に問題がないのではないかと思います。

しかし、正規表現の場合、それは確かにあなたがもっと意識しなければならないことを意味します： varname -> \{?varname\}?

@rjmholtここで分析を?で終わる一意の変数は約70個しかありません

おかげで、@mburszley -私にはそれになりバケツ3：そうもない灰色の領域の変更、の必要性をユーザーに負担をかける{...}並列、非常に残念なことであるため、不幸な必要性$(...)の周りにexit &&および||のコンテキストでのexit / return / throwステートメント。

その問題から推論を借りるには：

?.使用できるように、変数名の前後に{...}の使用を強制すると：

• 新規ユーザーは{...}の必要性を期待せず、以下が失敗したときに_it_が必要であることを必ずしも知りません（ Set-StrictMode -Version 2以上が有効でない限り、おそらく_undetected _）： $o = [pscustomobject] @{ one = 1 }; $o?.one

• ユーザーが{...}の必要性を知ったとしても：

  • 直感に反する必要があるため、時々使用するのを忘れてしまいます。
  • 彼らが覚えているとき、特に{...}は入力が難しいので、この一見人工的な要件は継続的なフラストレーションの原因になります。

この問題は修正済みとしてマークされており、 1日間アクティビティがありません。 ハウスキーピングのため閉鎖されています。

@ rjmholt 、 https ：

既存の有効な構文を解析する方法を壊さないことが正しい方法でした。 繰り返しになりますが、変更は、少数のワイルドプログラムをサポートすることを決定した場合だけではありません。長所が短所を上回っていると思った場合に、多くの重大な変更を加えました（私が個人的に同意するわけではありません）。それらのすべてで、またはそれらが他の人を正当化するかしないか）。 問題は、トークナイザーまたはパーサーの一部の側面を変更すると、2つのPowerShellバージョンが一部のスクリプトに対して同じASTを生成しなくなるため、2つのPowerShellが同じスクリプトを異なる方法で「認識する」ことです。 つまり、構文を同じ方法で読み取ることすらできないため、PSScriptAnalyzerルールを記述して、その周りで発生する可能性のある問題を検出することはできません。 PSScriptAnalyzerは、PowerShellのバージョンごとに異なる構文を表示します。

C＃とは異なり、PowerShellは、後で実行するために互換性のある形式に異なる構文をプリコンパイルすることはできません。つまり、構文の変更はランタイムに関連付けられます。 PowerShellが構文を中断すると、異なるバージョンに対して機能するスクリプトの数が減ります。つまり、ユーザーは2つのスクリプトを作成する必要があります。これは、シェルとスクリプト言語にとって深刻な問題です。 PowerShellは、1つのスクリプト内のロジックとのすべての違いを乗り越えるのに十分な動的であると想定されていますが、構文は、交渉の余地なく静的なものの1つです。 また、前後の両方が有効な場合に構文を変更することは特に有害です。これを検出する簡単な方法がないため、警告はなく、両方の環境で実行した後でも、ユーザーは異なる動作が発生したことを知らない可能性があります。

一般に、このような変更は非常に問題になる可能性があり、長所が短所を上回っている場合にのみ行う必要があります。重要な要素は、既存のコードがどれだけ壊れているかです。

異なるバージョンに対して機能するスクリプトの数を減らします
つまり、ユーザーは2つのスクリプトを作成する必要があります

ここでは_new_構文機能（ ?. ）について話しているので、定義上、それを使用するスクリプトは古いバージョンでは実行できません（つまり）。レガシーバージョン互換のコードパスを提供する条件を特に追加しない限り、しかし、それだけの価値はほとんどないようです。そうすれば、レガシー機能を使い続けることができます。

はい、変数名として$var?を使用していた古いスクリプトの$var?.fooの解釈は壊れますが、次のようになります。

• ?は、 {...}囲むことなく、識別子の一部として許可されるべきではありませんでした。

• そうすることができるのは予想外であり、おそらく多くの人にとっては_不明_であるため、個人的な経験から言えば、そのような変数名は実際には非常にまれですが、 @ mburszleyの分析はより具体的な証拠を提供します。

  • Rubyでさえ、識別子の_end_で? （および! ）のみを許可し、_method_識別子のみを許可します。ほとんどのRubyユーザーは、他の言語がサポートしていると想定してはならないことを認識していると思います。同じこと。

だから、実用的に言えば：

• 既存のコードの大部分は影響を受けません- $var?.fooなどのトークンは単に検出されません。

• 新しいセマンティクスで$var?.fooを記述した場合、そうです。古いバージョンでそれを実行すると、有効な厳密モードに応じて、（明らかな方法で中断するのではなく）異なる動作が発生する可能性があります。とにかく意図したとおりにコードを実行するために必要な最小バージョンを適用します_（ #requires -Version 、モジュールマニフェストキー）。

全体として、これはバケット3の変更の明確なケースです。技術的に破壊的な変更であり、既存のコードをほとんど破壊せず、実際のメリットを提供します（または、逆に、予期しない動作による永続的な頭痛の種を回避します）。

@ mklement0は、

いいですね、@ SteveL-MSFT-＃11379を参照してください。

私はここにいるすべての人に、そこで再びサポート（またはあえぎ、非サポート）を示すことをお勧めします。