Powershell: 提案：三項条件を実装する

ステートメントからの割り当てを許可するように変更すると、三項演算子の必要性が減ることに注意してください。 あなたは簡単に行うことができます
$var = if ($x) { $x } else { $y }
三項演算子ほど簡潔ではありませんが、間違いなく読みやすくなっています。

はい。ただし、条件がより大きな式の一部である場合は、 $(...)追加で使用する必要があります。

'The current sec. is ' + $(if ((get-date).tostring("ss") % 2) { 'odd'  } else  { 'even' })

対。

powershell 'The current sec. is ' + ((get-date).tostring("ss") % 2 ? 'odd' : 'even')

読みやすさが...ええと...読者の目にあることは知っていますが、個人的には後者の方が視覚的に解析しやすく、入力を少なくすることは常にボーナスです。

このように頻繁に使用される機能を使用すると、より抽象的な3項構文を覚えていても問題はないと思います（もちろん、必要に応じて、 ifを引き続き使用できます）。

@ mklement0後で同意する必要がありますが、認知的負荷が少なくなります。

これは間違いなく私のトップリストにあります。
@BrucePay 、これが悪い考えになる理由はありますか？ それとも、「出荷することは選択することです」ということですか？

過去には、この機能要求は、経験の浅いスクリプト作成者にとって理解しにくいものであり、ifステートメントの式形式はより冗長であるものの、より明確であるとして却下されていました。

私の個人的な見解：もしその言語が私のためだけだったら、私はおそらくずっと前にそれを追加したでしょう。 しかし...私は多くの開発者がそれを使用していないことを発見しました。これは、経験の浅い人々が三項演算子に問題を抱えるという仮説にいくつかの真実があることを実際に示唆

@lzybkr ：

機能の_積極的な使用_とそれを_認識_して理解する能力を区別する価値があります。

明らかに、誰もがそのような機能を使用するかどうかを選択できますが、「問題がある」とは、経験の浅い人が他の人のコードでそれを見たときにそれを「理解」しないことを意味すると言っていますか？

@ mklement0 - $_が不可解で混乱しているという十分なフィードバックがあるため、 $_エイリアスとして$psitemを導入しました。したがって、三項演算子は少し難しいと思います。理解する経験豊富な人々。

一方、PowerShellには、初心者や経験豊富な開発者にとっても混乱を招く要素がたくさんあります。

他の言語と同様に、言語構造の構文と意味を学ぶにはある程度の努力が必要です。
三項演算子が特に把握しにくいと思うかどうかはわかりません。

それを示唆するデータはありますか？

唯一のデータは逸話的だと思いますが、批判はあらゆる不可解な言語（bash、perlなど）に当てはまります。

そして明確にするために、私は歴史的背景を提供していました。 おそらく、PowerShellはどこにでもあるので、より不可解な構文が採用に影響を与えることはありません。

また、覚えておいてください-一部の簡潔な言語では、if / thenを三項演算子として使用します（例：F＃）。

とは言うものの、使用する文字数を減らして、あまりわかりにくいものにしないことも可能かもしれません。

if ($x) { $y } else { $z }
$x -then $y -else $z
$x ? $y : $z

-then/-elseはPowerShell構文によく適合しますが、演算子（または、単一の演算子と考えるには混乱しすぎる場合は演算子）を使用すると、括弧や中括弧が不要になるという利点があります。

繰り返しになりますが、これはforeachとforeach-objectような問題を求めています。 でも多分それほど悪くはないでしょう、私にはわかりません。

@lzybkr ：

ホメオパシー用量の暗号は健康的です：

PowerShellは全体的に不可解ではありませんが、場合によっては、頻繁に使用される構成、特にWhere-Objectと% ?に対して、簡潔な_代替_（必要に応じて冗長にすることもできます）として不可解な構文を提供します。 % for ForEach-Object 。

提供$x ? $y : $zする簡潔な代替としてif ($x) then { $y } else { $z }私には、同じ精神です。

不可解な側面は、 ?が_question_を彷彿とさせるため、条件付き（この場合は? 1つに先行しますが）を示唆し、さらに重要なことに、いくつかの潜在的に馴染みのある構成要素であることによって改善されます。他のlanguages_、同じ基本的なセマンティクス。

$x -then $y -else $zでは同じメリットは得られません。なじみがありません。

また、多くのPSオペレーターには記号名がありますが、多くはありません： * / + % ...
これらも本質的に不可解であり、非常に馴染みがあり、どこにでもあるため、私たちはもはやそのように認識していません。

私の感覚では、 $x ? $y : $zもすでに多くの人に馴染みがあり、簡潔な条件が頻繁に必要になることを考えると、言語に導入されるとさらにそのようになるでしょう。

この演算子で指定できるものはかなり制限されることに注意してください。 特に、コマンドを括弧で囲まない限り、コマンドを使用することはできません。

(test-path foo.txt) ? (get-content foo.txt) : (get-content bar.txt)

と比べて

if (test-path foo.txt) {get-content foo.txt} else {get-content bar.txt}

また

get-content ((test-path foo.txt) ? "foo.txt" : "bar.txt")

vs

get-content $(if (test-path foo.txt) {"foo.txt"} else {"bar.txt"})

私の考えでは、簡潔さという点ではほとんど利点がなく、読みやすさには明らかな欠点があります。 式指向言語を使用している場合、三項演算子はそれほど面白くありません。 私が16年前にこの言語を使い始めたとき、三項演算子を追加することは、Cのバックグラウンドから来ていることは明らかであるように思われました。 今、私たちはそれを追加しなかったことをうれしく思います。 雑然とした感じです。

特に、コマンドを括弧で囲まない限り、コマンドを使用することはできません。

これは、_any_PowerShell演算子に適用されます。

すべてのPowerShellステートメントにコマンドが含まれているわけではありません。コマンドが含まれている場合、ユーザーは(...)がコマンドの入場料であることをすでに知っています（ほとんどの場合）。

あなた自身の例では、私にとって((test-path foo.txt) ? "foo.txt" : "bar.txt")は$(if (test-path foo.txt) {"foo.txt"} else {"bar.txt"})上回っています。これは、 $(...)が必要であるという曖昧さと、中括弧によってもたらされるノイズの両方が原因です。

多分それは私だけですが、私はこれを見つけます：

get-content ((test-path foo.txt) ? "foo.txt" : "bar.txt")

これよりも視覚的にスキャン/解析するのがはるかに簡単です：

get-content $(if (test-path foo.txt) {"foo.txt"} else {"bar.txt"})

この問題についての私の唯一の不満は、3項?:を実行する場合は、null合体??も実行する必要があるということです。

$logDir = $env:LogDir ?? "$PSScriptRoot\Log"

Invoke-TernaryおよびInvoke-NullCoalescingの実装を実際にいくつか見てきました（例：https：//github.com/dahlbyk/posh-git/blob/master/src/Utils.ps1#L12）。 この種のことは、そのような機能が言語に組み込まれていることに対する一般的な要望があることを示しています。

@rkeithhill ：同意します。 re null-coalescing：すでに問題があり、null-soakingもカバーしています：＃3240

したがって、経験の浅いコーダーの議論では、null合体または3進コードステートメントを簡単に使用することはできません。少し近視眼的だと思います。 これらの「高度な」機能を使用する必要はありません。プログラマーが経験不足のためにコードを読むことができない場合、個人的には、新しいことを本当にすばやく学ぶ必要があるという私の手がかりです。
私がC＃で三項を最初に見たとき、私はWTFがMSが導入したこの新鮮な地獄のようでした。これを読むのに数分かかるまで、それから私は夢中になりました。

POSHの実際の例では、次の行があります。
$mc_object = ($Message.fields | where Name -Match appname).Content
$ Messageオブジェクトに「アプリ名」という名前のfiledプロパティがない場合を除いて、これは問題ありません。また、これが由来するJSON形式のデータを制御しないため、何をすべきかを判断する必要があります。

したがって、null合体演算では、最後に?? ""を追加して、元のセッターがnullであっても、$ mc_objectが常に有効な文字列であることを確認するだけです。 そうでなければ、4つのキーストロークでできることを達成するために、いくつかの異なるテクニックを実行する必要があります。
$mc_object = if(-not ($Message.fields | where Name -Match appname).Content)){""}else{($Message.fields | where Name -Match appname).Content}
それは私には非常に読みにくいですが、それから私はこのようなことをすることによってこれを少しきれいにすることができます、それは私がしていることです。
$mc_object = ($Message.fields | where Name -Match appname).Content if(-not $mc_object){$mc_object = ""}

ひどいことではありませんが、null-coelasceに押されている4つ以上のキーがたくさんあります。

とにかく、私は間違いなくPowershellの三元およびnull-coelasceに投票します。これにより、いくつかの非常に高度な機能が追加され、Powershellが任意のシステムの「コア」形式で使用するのがより魅力的になります。

@lzybkr実際に$PSItem採用している人はまだいません。 私はスクリプトを作成するかなり大規模なチームで働いていますが、経験の浅いPowerShellユーザーでさえ、全員が$_使用しています。

@tibmeisterまたは...

if (-not ($mc_object = $Message.fields.where{$_.Name -match 'appname'}.Content)) {
    $mc_object = ''
}

式としての割り当ては通過しますが、信じられないほど判読できません。

私は定期的に$ psitemを使用しています

Scripting Gamesの審査で何年にもわたって、$ psitemが回答に多く使用されました

@RichardSiddaway ：PowerShellタグ付きの質問でStack Overflowを見ると、_ 2014年以降に尋ねられた_、次のようになります（この記事の執筆時点）。

• 約 powershellタグ付けされた106,000件の
• これらのうち、71にはPSItemという単語が含まれています（そのうち13は質問です）。つまり、1％未満です。

$PSItemは2012年9月にv3で導入されたため、安全のため、クエリの開始日として2014を選択しました。

これは正確な指標ではありませんが、残念ながら、このサイトでは$_または_を検索できません。また、_どちらでもない_ $_を含む質問があると確信しています。 $PSItem 、v3以前の質問もまだ聞かれています- $_は$PSItemよりもはるかに頻繁に使用されていると結論付けるのは安全だと思います。

ただし、より大きなポイントは、_選択_する必要がないということです。

$PSItemと$_幸せに共存するのと同じように、 ForEach-Objectと% 、 Where-Objectと? 、.. 。：

$a ? $b : $cはif ($a) { $b } else { $c } / $(if ($a) { $b } else { $c })と共存できます

$a ? $b : $cを導入する_肯定的な_理由を取り戻すことに関して

• ほとんどのプログラマーに馴染みのある構文を使用して、より簡潔で視覚的に雑然としません。

• $(...)の必要がないため、より効率的です。 ifステートメントは、より大きな式の一部として使用できるようにするために必要です（これは、ノイズが多く、効率が低く、意図しない側面を持つ可能性があります）。効果）

あいまいさの懸念について：

（（単純な）引数を使用して単に_コマンドを呼び出すのではなく）_expressions_を書いている人は、ある程度の開発者の経験があると見なすことができます。私の（逸話的な）感覚では、ほとんどの開発者は少なくとも$a ? $b : $cを凝縮されたifとして認識しています。

ただし、説明しなくても簡単に説明でき、非自明な_symbols_を使用することを除けば、概念の複雑さはif ($a) { $b } else { $c }と同じであり、
$(if ($a) { $b } else { $c })

一度導入されたものがうまくいくと仮定すると（確かに、この議論はそれに対する需要があることを示しています）、頻繁に遭遇すると、親しみやすく、簡単に認識できるイディオムになります（つまり、より簡潔で、入力しやすく、少なくとも私と他の数人にとってはここでは、より読みやすくなっています）-ほとんどの人が$PSItemよりも$_を好むようです。

mklement0、あなたは非常に素晴らしい例を持っています、そして私はポイントをはっきりと示していると思います、ありがとう。

これを読み直して再検討し、いくつかの質問を見ると、提案されているもう少し冗長な構文に傾倒していることがわかります。

$value = $a -eq $b -then $trueVal -else $falseval

または、より意味的に読みやすい構文の場合：

$value = $trueVal -if $a -eq $b -else $falseVal

@ vexx32最初の例は気にしませんが、式の途中の状態が非常に重いと思います。

ええ、私は同意する傾向があると思いますが、それはもう少し読みます...スムーズに。 しかし、私はまだ最初に行く傾向があります。

PowerShellがC＃の「オンランプ」言語になることを目的としていることを考えると、 ? :を使用するのが道だと思います。 JavaScriptでさえこの構文を使用しており、最近最も人気のある言語の1つです。 :-)

@rkeithhillは、他のいくつかの言語の構成に精通していることと、C＃でも?基づいているnull合体、nullソーキング、およびnull条件付きの割り当ても必要であることに同意しました。

後者の2つ（たとえば、 $foo?.barと$var ?= 'default val' ）は、シンボルベースの表現なしでは実際には不可能であり、null合体の場合でも$a ?? 'value-if-null'は$a -elseifnull 'value-if-null'ようなものよりも好ましいようです。

? 、 Where-Object頻繁に使用されるエイリアスとして、すでに_条件付き_を表すものとしてしっかりと定着しているため、その知識をその使用法のバリエーションに転送することは論理的であるように思われます。

PowerShellは本当にC＃へのランプですか？ 私はそれが10〜12年前に表明された意図であったことを知っていますが、それは本当に起こっているのでしょうか？ 私の疑惑は、PowerShellユーザーの大多数にとって、C＃は行きたい場所にいないということです。

三項条件が発生する場合は、次のようなものを見たいと思います
$ value = $ trueVal -if $ a -eq $ b -else $ falseVal

@ vexx32が述べたように

これは、平均的なPowerShellユーザーにとってより理にかなっています。

@ mklement0 $ psitemに関する私のコメントは、私の個人的な経験に基づいています。 あなたが別の経験をしたことがあるなら、それは私の経験を無効にすることはありません

私はそれが10〜12年前に表明された意図であったことを知っています

うん、ジェフリーによる他の場所の中で初期のMVPサミットで。 それ以来、何の違いも聞いていません。

また、ほぼすべての条件付き/ループ構造は、C＃（およびC系統）、 if {} 、 while {} 、 do {} while 、switch {} ,から取得します。 for {} , foreach {} , try {} catch {} finally {} `。 この条件付き構成もそうなることは私には理にかなっています。

ただし、これらは言語のキーワードです。@ rkeithhill。 演算子はまったく異なります。

PowerShellで使用される演算子の大部分は、同等のC＃演算子とはかなり異なることがわかると思います。 PSチームは、大多数のオペレーターのために、より説明的な構文を非常に明確に選択しました。

三項の振る舞いも、利用可能なより冗長な構文オプションの後に取るべきだと思います。 PowerShellは、C＃への「オンランプ」として考えられていた可能性がありますが、それは、PowerShellがよりシンボリックな構文を継承する必要があるという意味ではありません。 確かに、それが丹念に避けられてきた場所はたくさんあります。

もしそうなら、シンボリック構文に対するあなたの議論は、他の一般的なプログラミング言語がこの概念をかに根ざしてませんでした。代わりに、賢明にできる限り記述的な構文で作業することを好みました。 すでにC＃の経験があるユーザーがそのような構文に精通しているからといって、それを使用する理由にはなりません。

PowerShellがC＃またはその他の言語への「オンランプ」言語である場合（これは、これまでのところかなりうまくいくと思います）、ここで最小公分母を検討し、最も経験の浅い人が何を見つけるかを考える必要があります賢明で直感的です。

私が提案した解決策がそれであると言っているわけではありませんが、この観点から、それらはおそらくより賢明な方向に向かっていると思います。

@ vexx32
これらの演算子はどうですか？

.
=
[]
,
+ - * / %
++ --
+=  -=  *=  /= %=

一般的に、C＃の先導に従うことが常に適切であるとは限らず、PowerShellの精神を維持することが優先されるべきであることに同意します。

逆に、同じ構文がもっともらしいと思われる場合は、C＃から逸脱しないことをお勧めします。私にとって、手元にある提案は、＃3240とともにその一例です。

他の言語を脇に置いておくと：

• ?の現在のセマンティクスは、提案された演算子に拡張されていると考えられます。

• 提案されている_related_演算子に値が表示された場合（nullソーキング（ ?. ）、null合体（ ?? ）、null条件付き割り当て（ ?= ））、選択します-then / -elseような冗長な三部形式の場合、これらの関連するすべての演算子に共通性（明らかに概念的にはある）を反映させたい場合は、オプションではありません。

機能がエキゾチックであるほど、冗長性​​が重要になります。

機能を頻繁に使用するほど、簡潔さが重要になります。 そして、シンボルベースの表現の抽象性は、たとえば*場合と同様に、構文に繰り返しさらされることで問題になりません。

私に話し合っているすべてのオペレーターは、後者のカテゴリーに分類されます。

@RichardSiddaway ：

$ psitemについての私のコメントは、私の個人的な経験に基づいています。 あなたが別の経験をしたことがあるなら、それは私の経験を無効にすることはありません

はい、あなたのコメントは_個人的な_経験に基づいていました。
私は、人気のあるQ＆AサイトのStack Overflowからの_データの分析_に基づいて、（述べられた制約の範囲内で）_一般的な_使用パターンを推測しました。これは私の個人的な経験とは関係ありません。

あなたの個人的な観察が「トランスパーソナル」な真実を反映していると信じる場合、私のコメントを無効と見なすことができる唯一の理由-あなたがコメントでそのように主張しなかった。 あなたはそれを作るつもりでしたか？ もしそうなら、私たちは_それ_について議論する必要があります。

これらの演算子のほとんどすべては、比較的明確に理解されている意味を持つ数学演算子です、 @ mklement0😄

三項演算子は条件演算子であり、PSのブール/条件演算​​子の_all_はより冗長な形式です： -and 、 -or 、 -eq 、 -ne 、 -containsなど。

ただし、周囲の機能と関連する演算子が必要なため、この省略形が理にかなっている場合があることに同意します。 しかし、「標準」の3項構文は、まだ繰り返し使用されていない私たちにとっては特に直感的ではないと思います。

演算子は数学演算子です

リストされているものの中で、 + - * / %が（純粋に）数学的な意味を持っていますが、明確に理解されている側面は他のものにも当てはまります（ =除いて、平等テストと混同されることがよくあります） ）。

<condition> ? <if-true> : <else>と比較するためのより良い構成は、他の演算子ではなく、 if _ statement_です。 ifは間違いなくより冗長ですが、三項演算が対処することを意図しているのはまさにその側面です（ ifとは異なり、真の構成可能な式であることに加えて）。

確かに簡潔さの範囲はありますが、あなたが言うように、一貫した方法で提案されているすべての関連する演算子に対応するには、シンボルベースの構文が理にかなっています。

まだ繰り返しさらされていない私たちに。

まあ、それはうまくいけばすぐに変わるでしょう。 😁
要点はわかりますが、（a）構文は簡単に説明でき、 ifステートメントと同じ概念の複雑さを持ち、（b）繰り返し公開するとメモリの保持に役立ちます。

@ mklement0 ?が有効な名前の文字であることに対処することをどのように提案しますか？ 大きな変化？ 私は、PowerShellコアを使用している人は、そのままPowerShellに精通していると考えており、追加の構文（50年近く他の言語で存在している）は支障にはなりません。 より詳細な情報が必要な場合は、いつでもif/else使用できます。

?は、コマンドモードでのみ有効なエイリアスです。 式モードのすべてのバリエーションで、現時点では単に無効な文字です。 衝突はありません。

このコードを入力しようとすると、単にエラーになります。

$Value = $true
$Value ? "Hello!" : "Goodbye!"

結果：

At line:1 char:8
+ $Value ? "Hello!" : "Goodbye!"
+        ~
Unexpected token '?' in expression or statement.
+ CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : UnexpectedToken

@ vexx32

$what? # <- example of a valid variable name

彼のヌルソーキングの例では、 $var?.maybenull()は疑問符がそこにあることを気にせず、誰かが過度に凝縮しようとすると、その三項が壊れます。

申し訳ありませんが、それは主にそれに関する他の問題で議論されていたので、あなたがそれについて言及しているとは思いませんでした。

有効な変数名の文字であると除外できるかどうかはPSチーム次第ですが、デフォルトで変数名の文字と見なされないようにすることはそれほど問題にならないという意見になりがちです。 変数名の一部として実際に?を使用している人を見たことがないと思います。

@ vexx32ええ、

$var = $test?$thing1:$thing2

しかし、シェルに住んでいる私たちにとっては、エッジケースで髪を分割しすぎている可能性があります。

修正：

$var = ${test}?${thing1}:$thing2

@ mklement0-私は必ずしも同意しません：

比較するためのより良い構成？：toはifステートメントであり、他の演算子ではありません。 ifは間違いなくより冗長ですが、三項演算が対処することを意図しているのはまさにその側面です（ifとは異なり、真の構成可能な式であることに加えて）。

具体的には、C / C＃はステートメント指向の言語ですが、条件式が必要なため、三項演算子が存在します。

式指向言語（F＃やRustなど）では、不要と見なされるため、簡潔な構文はありません。 三項演算子を削除するRustに関するこの古い

Rustで私が本当に気に入っていることの1つは、エラー処理に?演算子を使用することです。 PowerShellで?を使用する具体的な提案はありませんが、条件式よりも?方がエラー処理に適しているようです。

@ TheIncorrigible1 、 @ vexx32 ：はい、 nullに浸すことは技術的には重大な変更ですが、できればバケット3タイプです（実際、そこで議論を続けましょう）。 三項演算の場合、曖昧性解消のために?前に{...} /空白を使用することをお勧めしますが、この問題は解決しているようです。

@lzybkr ：

具体的には、C / C＃はステートメント指向の言語ですが、条件式が必要なため、三項演算子が存在します。

PowerShellでは、 ifなどのフロー制御ステートメントは_half_-expressionsです。 _simple_式では、提案された3項演算は同等です。 _nested_のものでは、次のようにはなりません。

$foo = $True  ?     1   :      0    # proposed ternary
$foo = if ($True) { 1 } else { 0 }  # equivalent `if` statement

$foo = 1 + ($True  ?     1   :      0)   # nesting OK; note that + would have higher precedence
$foo = 1 + if ($True) { 1 } else { 0 }  # !! doesn't work
$foo = 1 + (if ($True) { 1 } else { 0 })  # !! doesn't work, even with parentheses
$foo = 1 + $(if ($True) { 1 } else { 0 })  # only $(...) (and situationally @(...)) work

$() / @()の必要性は、構文上の不便さだけではありません。動作とパフォーマンスに影響があります。

そうは言っても、 ifやforeachなどのステートメントが正真正銘の表現であることを_望みます_（現在失敗しているもののもう2つの例： foreach ($i in 1..5) { $i } | Write-Outputまたはforeach ($i in 1..5) { $i } > out.txt ）。
ただし、それらが_できない_かどうか、および/または下位互換性の懸念があるかどうかを判断するのに十分なことはわかりません。
参照：＃6817

ifがPowerShellで完全な式になる場合は、Rustから3項条件を削除することになった引数を作成できます。その場合、それはもはや_必要ではありません_。

しかし、この提案に対する私の動機は決して_必要性_ではありませんでした-それは簡潔さ、便利さ、そして読みやすさ（視覚的な混乱）についてです。

使用する具体的な提案はありませんか？ PowerShellで、しかしそれはのように感じますか？ 条件式よりもエラー処理に適しています。

C＃とは根本的に異なるセマンティクスで?を導入することは、永遠の混乱の原因になると思います。

これとは別に、PowerShellのエラー処理の改善については議論する価値があります。

If / Then / Elseの簡潔で直感的でない代替案を探している場合は、すでに1つあります。

( 'False', 'True' )[( Test-Condition )]

そして、それは式で機能します。

"This statement is " + ( 'False', 'True' )[( Test-Condition )]

@TimCurwick ：それは簡潔です（そしてもっとあいまいです）が、同等ではありません：提案された三項条件は_short-circuiting _（ ifステートメントのように）ですが、構文は常に_both_の選択肢を評価します。

とは言うものの、あなたの構文は、述べられた制限を知っていると仮定すると、確かに現在利用可能な次善の策です。

PowerShellで3項の選択肢を表示する方法の説明に関して、 -replace / .replace()使用されているのと同じ形式のオプションを検討した人はいますか？

$a -eq $b -ternary $a,$c
$true -ternary 1,0

また

($a -eq $b).ternary($a,$c)
($true).ternary(1,0)

これにより、演算子が文字通り三項と呼ばれることにより、三項アクションを実行していることが明確になります。 冗長ですが、まだ記述が短く、 -operator $first,$secondの既存の一般的な動作を利用しているため、あらゆる経験のPowerShellユーザーに馴染みがあるはずです。

🤔それはうまくいくかもしれませんが、提案されたどの代替案よりも厄介です。 -replaceは、引数の実際の配列を受け入れるだけなので、そのように機能します。 .Replace()はPSチームによって管理されていません。これは.NET System.Stringクラスのメソッドです。

これらの構文のいずれかを使用しようとすると、ETSメソッド（これは問題ありませんが、アタッチする必要のあるオブジェクトの作成にパフォーマンスのオーバーヘッドが少し追加される傾向があります）、またはオペレーターバージョンのいずれかを意味します。あなたが提案するように、引数として配列を簡単に持つことはできません。

パーサーでそのようなオペレーターを特別なケースに入れなければ、短絡することはできません。 他の言語の3項構文は、実際に両方のオプションを評価することを_望まない_ため、一般的に存在します。 両方のオプションを完全に評価する必要はなく、正しいブランチのみを評価する必要がある場合は、計算時間が短縮されます（重大な副作用が発生する可能性があります）。

また、これにはすでに特殊な大文字と小文字が必要になるため、混乱を最小限に抑えるために、新しい構文を導入する方が効果的です（配列のように見えるが、配列のように使用できないものがあると、少し誤解を招く可能性があります。たとえば、事前に「配列」を作成し、それを変数として渡すことはサポートされません）。 メソッド引数がすでに配列構文と少し矛盾しているという事実は、多くの場合、すでに誤解を招く可能性があります。 カンマの_third_バリアント動作をミックスに追加したくないと思います。

@ PowerShell / powershell-委員会はこれについて詳細に議論しましたが、全員が同意するわけではありませんが、大多数は、この演算子を使用し、C＃構文に合わせて?:を維持することに価値があることに同意しています。 C＃開発者からのものである。 この機能は、実際の使用に関するフィードバックが保留されている実験的なものになります。

@ SteveL-MSFTつまり、この機能は7.0に向けて前進しているということですか？ シンボルで?を使用できる変数の互換性が失われますか？

@ TheIncorrigible1はい、この機能はPS7で前進しています。 ?エイリアスを使用しても互換性が損なわれることはありません。 Where-Objectとternaryを区別しようとしているスクリプトを見ると、 ?視力に懸念がありますが、これに関するユーザーのフィードバックを確認します。 一般に、ほとんどのユーザーがこの演算子を使用することは期待していませんが、それによって前進が妨げられることはありません。

@ SteveL-MSFT $isValid?などの名前の変数を意味します。 これらは、PSの現在の反復で有効なトークンです。

@ TheIncorrigible1 ：

最初のオペランドと?間に空白を要求すると、前述のようにその問題が解決されます。私にとっては、これは完全に合理的な解決策です。

• $number:42は、_全体として_単一の変数参照として解釈されるため、 $true ? $number:42ようなものは機能しないため、 : _ also_はその周りに空白を必要とします。

• C＃はtrue?number:42許可しますが、そのレベルでの互換性について心配する必要はないと思います。 私は個人的に簡潔さを大切にしていますが、読みやすさを犠牲にすることはありません。 $true?$number:42書くことができたとしても、書きません。

（（ヒント、ヒント） null条件付きアクセスを実装する場合、下位互換性は確かに問題になり@ KirkMunroが最近主張したように、識別子名に関するPowerShellの許容性は一般に問題がありますが、その船は出航しました）

ええ、空白の要件を残すことは賢明だと思います。 結局のところ、それはそれなりに簡潔です。 😁

プロトタイプは、三項演算子（式を期待していることがわかっている場合）のコンテキストで、 ?と:を含む数値を異なる方法で解析しようとしました。 したがって、 ${isWindows}?12:47ようなものを書くことができます。
123?や1:23ような数値は、今日では汎用トークンとしてトークン化されています。これは、式を期待していることがわかっている場合にはまったく役に立ちません。

変数の場合、変数は式であるため、変数名に?または:を使用する方法はまったく変更されません。

良い点、@ daxian-dbw; {...}を使用して変数名の境界のあいまいさを解決できることを忘れたので、コードゴルファーは${isWindows}?${number}:47ようなものを使用できると思います

これを閉じてもいいですか？

＃10367で閉じる