Powershell: 제안: 삼항 조건문 구현

명령문에서 할당을 허용하도록 변경하면 삼항 연산자의 필요성이 줄어듭니다. 당신은 단순히 할 수 있습니다
$var = if ($x) { $x } else { $y }
삼항 연산자만큼 간결하지는 않지만 틀림없이 더 읽기 쉽습니다.

예, 조건이 더 큰 표현식의 일부인 경우 $(...) _in 추가_ 사용해야 하지만:

'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')

나는 가독성이 ... 어 ... 독자의 눈에 달려 있다는 것을 알고 있지만 개인적으로 후자가 시각적으로 구문 분석하기 더 쉽고 덜 입력해야 하는 것은 항상 보너스라고 생각합니다.

이렇게 자주 사용되는 기능을 사용하면 더 추상적인 삼항 구문을 기억하는 것이 문제가 되지 않을 것이라고 생각합니다(물론 사람들이 원하는 경우 계속 if 을 사용할 수 있음).

@mklement0 나중에 인지 부하가 ​​적다는 데 동의해야 합니다.

이것은 확실히 내 상위 목록에 있습니다.
@BrucePay , 이것이 나쁜 생각이 될 이유가 있습니까? 아니면 '배송은 선택하는 것'에 관한 것입니까?

과거에 이 기능 요청은 경험이 부족한 스크립터가 이해하기 어렵고 if 문의 표현 형식이 더 장황하지만 더 명확하다는 이유로 거절되었습니다.

내 개인적인 관점: 언어가 나만을 위한 것이라면 아마 오래 전에 추가했을 것입니다. 하지만 ... 많은 개발자 들이 그것을 사용하지 않는다는 것을 알게 되었는데, 이는 실제로 경험이 적은 사람들이 삼항 연산자에 문제를 겪을 것이라는 가설에 약간의 진실이 있음을 시사합니다.

@lzybkr :

기능의 _적극적 사용_과 기능을 _인지하고 이해하는 능력을 구별하는 것은 가치가 있습니다.

분명히 모든 사람이 그러한 기능을 사용할지 여부를 선택할 수 있지만 "문제가 있다"는 것은 경험이 적은 사람들이 다른 사람의 코드에서 그것을 볼 때 _이해하지 못할 것이라는 의미입니까?

@mklement0 - $_ 가 애매하고 혼란스럽다는 충분한 피드백 때문에 $psitem 를 $_ 의 별칭으로 도입 $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 및 % ? 대해 간결한 _대체_(원하는 경우 여전히 장황할 수 있음)로 암호 구문을 제공합니다 % ForEach-Object .

$x ? $y : $z 에 대한 간결한 대안으로 if ($x) then { $y } else { $z } 를 제공하는 것도 같은 정신입니다.

? 이 _question_을 연상시키므로 조건부(이 경우 ? 가

$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")

대

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"})

이 문제에 대한 나의 유일한 불만은 삼항 ?: 을 수행하려는 경우 null-coalescing ?? 도 수행해야 한다는 것입니다.

$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-coalescing 또는 삼항 코드 문을 쉽게 사용할 수 없을 것입니다. 이러한 "고급" 기능을 사용하기 위한 요구 사항은 없으며 프로그래머가 경험이 부족하여 코드를 읽을 수 없다면 개인적으로 그것이 새로운 것을 정말 빨리 배워야 한다는 신호입니다.
C#에서 삼항을 처음 보았을 때 나는 WTF가 MS가 도입한 이 새로운 지옥과 같았습니다. 이 내용을 읽는 데 몇 분 정도 시간이 걸렸습니다. 그러다가 푹 빠져버렸습니다.

POSH의 실제 예에는 다음 줄이 있습니다.
$mc_object = ($Message.fields | where Name -Match appname).Content
$Message 객체에 "app name"이라는 이름의 파일 속성이 없을 때를 제외하고는 훌륭하고 멋집니다. 그리고 JSON 형식의 데이터를 제어하지 못하기 때문에 무엇을 해야 할지 결정해야 합니다.

따라서 null-coalesce 작업을 사용하면 원래 setter가 null인 경우에도 $mc_object가 항상 유효한 문자열인지 확인하기 위해 끝에 ?? "" 를 추가하기
$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-coelase를 위해 4개 이상의 키를 눌러야 합니다.

어쨌든, 나는 Powershell에서 삼항 및 null-coelase에 확실히 투표합니다. 그것은 몇 가지 매우 고급 기능을 추가하고 Powershell을 모든 시스템에서 "코어" 형식으로 사용하기에 더 매력적으로 만듭니다.

@lzybkr 실제로 $PSItem 채택한 사람을 아직 보지 못했습니다. 저는 스크립트를 작성하는 꽤 큰 규모의 팀에서 일하고 있으며 경험이 덜한 PowerShell 사용자라도 여전히 모두 $_ 합니다.

@tibmeister 또는 ....

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

표현식으로서의 할당은 통과하지만 믿을 수 없을 정도로 읽을 수 없습니다.

나는 정기적으로 $psitem을 사용한다

수년에 걸쳐 Scripting Games $psitem이 답변에 많이 사용되었습니다.

@RichardSiddaway : 2014년부터 _asked된 PowerShell 태그 질문에서 스택 오버플로를 보면 다음을 얻습니다(이 글을 쓰는 시점 기준).

• 약 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 문이 더 큰 표현식(이는 더 시끄럽고 덜 효율적이며 의도하지 않은 측면이 있을 수 있습니다. 효과)

불분명한 문제에 관해서:

(단순한) 인수로 _명령을 호출하는 것과는 대조적으로 _표현식_을 작성하는 사람은 약간의 개발자 경험이 있다고 가정할 수 있으며 내 (일화적인) 감각은 대부분의 개발자가 최소한 $a ? $b : $c 를 if 로 _recognize_한다는 것입니다.

그러나 그렇지 않은 경우에도 쉽게 설명되며 명확하지 않은 _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도 이 구문을 사용하며 요즘 가장 인기 있는 언어 중 하나입니다. :-)

@rkeithhill , 둘 다 여러 다른 언어의 구성에 대한 친숙함과 _ 그리고_ C#에서도 ? 기반 인 null 병합, null-soaking 및 null-조건부 할당을 원하는 것에 동의합니다.

후자의 두 개(예: $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년 전에 명시된 의도였다는 것을 알고 있습니다.

예, Jeffrey가 다른 장소들 사이에서 초기 MVP 정상 회담에서. 나는 그 이후로 다른 것을 듣지 못했습니다.

또한 거의 모든 조건부/루프 구문은 C#(및 C 계보), if {} , while {} , do {} while , 스위치 {} , 에서 가져옵니다 while {} {} , foreach {} , {} catch {} finally {}`를 시도합니다. 이 조건부 구성도 마찬가지입니다.

하지만 @rkeithhill이라는 언어 키워드입니다. 연산자는 완전히 다릅니다.

PowerShell에서 사용되는 대부분 의 연산자는 C#에 해당하는 연산자와 상당히 다르다는 것을 알게 되실 것입니다. PS 팀은 대부분의 운영자를 위해 더 설명적인 구문을 선택했습니다.

나는 삼항 행동도 사용할 구문 옵션 자세한 더 이후에해야한다는 고려할 것입니다. PowerShell은 C#에 대한 '온 램프(on-ramp)'로 인식되었을 수 있지만 그렇다고 해서 더 상징적인 구문을 상속해야 한다는 의미는 아닙니다. 참으로 애써 피한 곳이 많다.

기호 구문에 대한 인수가 다른 일반 프로그래밍 언어 가 이 개념을 나타내는 따르지 않고 대신 합리적으로 만들어질 수 있는 설명적인 구문으로 작업하는 것을 선호합니다. 이미 C#에 대한 경험이 있는 사용자가 이러한 구문에 익숙하다고 해서 확실히 사용하는 이유는

PowerShell을 C # 또는 다른 언어로 '진입로'언어의 경우, 우리는 여기에 가장 낮은 공통 분모를 고려하고 가장 미숙 한 사람이 찾을 것입니다 무슨 생각해야 (I 느낌, 그것은 지금까지이에 상당히 잘 수행) 합리적 이고 직관적 입니다.

내가 제안한 솔루션이 다라고 말하는 것이 아니라 이러한 관점에서 보다 합리적인 방향으로 나아갈 가능성이 있다고 생각합니다.

@vexx32
이 연산자는 어떻습니까?

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

일반적으로 C#을 따르는 것이 항상 적절한 것은 아니며 PowerShell의 정신을 유지하는 것이 우선되어야 한다는 데 동의합니다.

반대로 동일한 구문이 그럴듯하게 맞는 것처럼 보이는 경우 C#에서 벗어나지 말라고 조언합니다. #3240과 함께 현재 제안이 그 예입니다.

다른 언어는 제쳐두고 다음을 수행합니다.

• ? 의 현재 의미는 제안된 연산자로 그럴듯하게 확장됩니다.

• null-soaking( ?. ), null-coalescing( ?? ) 및 null 조건부 할당( ?= )과 같은 _related_ 연산자가 제안되는 경우 선택 -then / -else 와 같은 장황한 삼항 형식의 경우 이러한 모든 관련 연산자가 공통성(개념적으로 분명히 갖고 있음)을 반영하도록 하려면 옵션이 아닙니다.

기능이 이국적일수록 더 자세한 정보가 중요합니다.

자주 사용하는 기능일수록 간결함이 더 중요합니다. 그리고 심볼 기반 표현의 추상성은 예를 들어 * 와 마찬가지로 구문에 대한 반복적인 노출을 통해 문제가 되지 않습니다.

나에게 논의되는 모든 운영자는 후자의 범주에 속합니다.

@RichardSiddaway :

$psitem에 대한 내 의견은 내 개인적인 경험을 기반으로 합니다. 다른 경험을 한 경우 내 경험이 무효화되지 않습니다

예, 귀하의 의견은 _개인적인_ 경험을 기반으로 했습니다.
내 개인 경험과 관련이 없는 _일반적인_ 사용 패턴을 추론하기 위해 인기 있는 Q & A 사이트 스택 오버플로의 _분석 데이터_를 기반으로 했습니다.

당신의 개인적인 관찰이 "초개인적인" 진실을 반영한다고 믿는다면 내 의견을 무효화하는 것으로 인식할 수 있는 유일한 이유입니다. 만들겠다고 했지? 그렇다면 _that_에 대해 논의해야 합니다.

거의 모든 연산자는 의미가 비교적 명확하게 이해되는 수학 연산자입니다. @mklement0 😄

삼항 연산자는 조건 연산자이고 PS의 부울/조건 연산자의 _모두_는 더 자세한 형식입니다: -and , -or , -eq , -ne , -contains 등

그러나 주변 기능 및 관련 연산자가 필요하기 때문에 이 약칭이 의미가 있을 수 있다는 점에는 동의합니다. 그러나 나는 "표준" 삼항 구문이 이미 반복적으로 노출 되지 않은 사람들에게 특히 직관적이지 않다고 생각합니다.

연산자는 수학 연산자입니다

나열된 것 중 + - * / % 만 (순수한) 수학적 의미를 갖지만 명확하게 이해된 측면은 다른 것에도 적용됩니다( = , 평등 테스트와 종종 혼동된다는 점을 감안할 때 제외) ).

<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

그의 null-soaking 예제에서: $var?.maybenull() 는 거기에 물음표가 있는지 신경 쓰지 않으며 누군가가 지나치게 압축하려고 하면 삼항이 깨집니다.

죄송합니다. 그것은 주로 다른 호에서 논의되고 있었기 때문에 당신이 그것에 대해 언급하고 있다고 생각하지 않았습니다.

유효한 변수 이름 문자가 되는 것을 배제할 수 있는지 여부는 PS 팀에 달려 있지만 기본적으로 변수 이름 문자로 간주되는 것을 방지하는 것이 큰 문제가 되지 않는다는 의견입니다. 변수 이름의 일부로 실제로 ? 를 사용하는 사람을 본 적이 없는 것 같습니다.

@vexx32 예, 거기에 가져와야 합니다. 범위 지정에 주의하지 않으면 추가 영향이 있을 수 있습니다(이는 이미 문자열 확장에서 볼 수 있으므로 사람들이 어느 정도 익숙해야 함).

$var = $test?$thing1:$thing2

그러나 나는 껍질 속에 사는 우리들에게 가장자리 케이스에 머리카락을 너무 많이 쪼개는 것일 수 있습니다.

수정됨:

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

@mklement0 - 반드시 동의하지는 않습니다.

비교할 더 나은 구성?:to는 다른 연산자가 아니라 if 문입니다. if가 확실히 더 장황하지만 삼항 연산이 해결해야 하는 것은 바로 그 측면입니다(if와 달리 구성 가능한 진정한 표현인 것 외에도).

특히 C/C#은 명령문 지향 언어이지만 조건식이 필요하기 때문에 삼항 연산자가 존재합니다.

표현식 지향 언어(예: F# 또는 Rust)에는 불필요한 것으로 간주되는 간결한 구문이 없습니다. 삼항 연산자를 제거 하는 Rust에 대한 이 오래된

Rust에서 내가 정말 좋아하는 것 중 하나는 오류 처리를 위해 ? 연산자를 사용한다는 것입니다. PowerShell에서 ? 를 사용하라는 구체적인 제안은 없지만 ? 가 조건식보다 오류 처리에 더 잘 사용될 수 있을 것 같습니다.

@TheIncorrigible1 , @vexx32 : 예, null-soaking은 기술적으로 중요한 변경 사항이지만 희망하는 유형은 버킷 3입니다 . 삼항 연산의 경우 명확성을 위해 ? 앞에 {...} / 공백을 제안하는 것이 그 문제를 해결하는 것 같습니다.

@lzybkr :

특히 C/C#은 명령문 지향 언어이지만 조건식이 필요하기 때문에 삼항 연산자가 존재합니다.

글쎄, if 와 같은 PowerShell 흐름 제어 문은 _half_-표현식입니다. _simple_ 식에서 제안된 삼항 연산은 동일합니다. _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 와 같은 명령문이 진정한 표현이 _희망_합니다(현재 실패하고 있는 두 가지 추가 예: foreach ($i in 1..5) { $i } | Write-Output 또는 foreach ($i in 1..5) { $i } > out.txt ).
그러나 _할 수 없는지_ 여부 및/또는 이전 버전과의 호환성 문제가 있는지 판단할 만큼 충분히 알지 못합니다.
참조: #6817

if 가 PowerShell에서 완전한 표현식이 된다면 Rust에서 3항 조건문을 제거한 인수를 만들 수 있습니다. 그러면 더 이상 _necessary_가 아닙니다.

그러나 이 제안에 대한 나의 동기는 _필요성_이 아니었습니다. 간결함, 편의성 및 가독성(시각적 혼란)에 관한 것입니다.

사용할 구체적인 제안이 없습니까? PowerShell에서는 ? 조건식보다 오류 처리에 더 잘 사용할 수 있습니다.

C#에서와 근본적으로 다른 의미를 가진 ? 를 도입하는 것은 영원한 혼란의 원인이 될 것이라고 생각합니다.

이와는 별도로 PowerShell의 오류 처리 개선 사항에 대해 논의할 가치가 있습니다.

If/Then/Else에 대한 간결하지만 직관적이지 않은 대안을 찾고 있다면 이미 하나가 있습니다.

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

그리고 그것은 표현에서 작동합니다.

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

@TimCurwick : 그것은 간결하고(더 모호하지만) 동등하지 않습니다. 제안된 삼항 조건은 _short-circuiting_( if 문과 같음)인 반면 구문은 _both_ 대안을 변함없이 평가합니다.

즉, 귀하의 구문은 명시된 제한 사항을 알고 있다고 가정하면 현재 사용 가능한 다음으로 가장 좋은 것입니다.

PowerShell에서 삼항 선택을 표시하는 방법에 대한 논의와 관련하여 -replace / .replace() 사용하는 것과 동일한 형식의 옵션을 고려한 사람이 있습니까?

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

또는

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

이것은 연산자가 문자 그대로 ternary 를 호출하여 ternary 작업을 수행하고 있음을 분명히 합니다. 장황하지만 쓰기에는 여전히 짧고 -operator $first,$second 의 기존 공통 동작을 사용하므로 모든 경험 범위의 powershell 사용자에게 친숙할 것입니다.

🤔 효과가 있을 수 있지만 제안된 어떤 대안보다 어색할 것입니다. -replace 는 실제 인수 배열을 허용하기 때문에 그런 식으로 작동합니다. .Replace() 는 PS 팀에서 관리하지 않습니다. .NET System.String 클래스의 메서드입니다.

이러한 구문 중 하나를 사용하려고 하면 ETS 메서드(괜찮지만 첨부해야 하는 개체 생성에 약간의 성능 오버헤드를 추가하는 경향이 있음) 또는 연산자 버전을 의미합니다. 당신이 제안한다면, 우리는 배열을 인수로 쉽게 가질 수 없을 것입니다.

파서에서 이러한 연산자를 특수 케이스로 지정하지 않으면 단락할 수 없습니다. 다른 언어의 삼항 구문은 일반적으로 두 옵션 모두를 실제로 평가하기를 _ 원하지 않기 때문에 존재합니다. 두 옵션을 모두 평가하는 것보다 올바른 분기만 평가해야 하는 경우 계산 시간이 더 빠릅니다(일부 심각한 부작용이 있을 수 있음).

그리고 그것은 이미 특별한 대소문자를 필요로 하기 때문에 혼란을 최소화하기 위해 새로운 구문을 도입하는 것이 더 효과적일 것입니다(배열처럼 보이지만 하나처럼 사용할 수 없는 것을 갖는 것은 약간 오해의 소지가 있습니다. 예를 들어 "배열"을 미리 만들고 변수로 전달하는 것을 지원하지 않습니다. 메소드 인수가 이미 배열 구문과 약간 충돌한다는 사실은 종종 이미 오해의 소지가 있습니다. 쉼표에 대한 _third_ 변형 동작을 혼합에 추가하고 싶지 않다고 생각합니다.

@PowerShell/powershell-committee는 이에 대해 길게 논의했지만 우리 모두는 동의하지 않지만 대부분의 사용이 예상대로 ?: 를 유지하는 C# 구문과 이 연산자를 사용하는 데 가치가 있다는 데 동의합니다. C# 개발자 출신이어야 합니다. 이 기능은 실제 사용 피드백이 있을 때까지 실험적입니다.

@SteveL-MSFT 즉, 기능이 7.0으로 이동한다는 의미입니까? 기호에서 ? 를 사용할 수 있는 변수의 호환성이 손상됩니까?

@TheIncorrigible1 예, 이 기능은 PS7에서 발전하고 있습니다. ? 별칭 사용과의 호환성이 깨지지 않아야 합니다. Where-Object 와 ternary 를 구별하려고 하는 스크립트를 볼 때 ? 시력에 대한 우려가 있지만 이에 대한 사용자 피드백이 무엇인지 알 수 있습니다. 일반적으로 우리는 대부분의 사용자가 이 연산자를 사용할 것으로 기대하지 않지만 이것이 앞으로 나아가는 데 방해가 되지는 않습니다.

@SteveL-MSFT 이름이 $isValid? 또는 이와 유사한 변수를 의미합니다. 이것은 PS의 현재 반복에서 유효한 토큰입니다.

@TheIncorrigible1 :

첫 번째 피연산자와 ? 사이에 공백이 필요하면 이전에 제안한 대로 해당 문제를 해결하며 나에게 완벽하게 합리적인 솔루션입니다.

• $number:42 가 _전체적으로_ 단일 변수 참조로 해석된다면 $true ? $number:42 와 같은 것은 작동하지 않기 때문에 : _또한_ 주위에 공백이 필요합니다.

• C#은 true?number:42 _does_ 허용하지만 해당 수준에서 호환성에 대해 걱정할 필요 또는 실제로 걱정할 수 있다고 생각하지 않습니다. 나는 개인적으로 간결함을 중요시하지만 가독성을 희생하지는 않습니다. 내가 $true?$number:42 _할 수 있더라도_ 쓰지 않을 것입니다.

((힌트, 힌트) null 조건부 액세스를 구현할 때 역호환성은 실제로 문제가 될 것입니다. @KirkMunro 가 최근에 주장한 것처럼 식별자 이름에 대한 PowerShell의 허용성은 일반적으로 문제가 있지만 그 배는 항해했습니다 )

예, 공백 요구 사항을 떠나는 것이 합리적이라고 생각합니다. 그것은 결국 충분히 간결합니다. 😁

프로토타입은 ? 및 : 된 숫자를 삼항 연산자의 컨텍스트에서 다르게 구문 분석하려고 매우 열심히 노력했습니다(여기서 표현식을 예상하고 있음을 알고 있음). 따라서 ${isWindows}?12:47 와 같은 것을 작성할 수 있습니다.
123? 또는 1:23 와 같은 숫자는 오늘날 일반 토큰으로 토큰화되며 표현식이 예상되는 경우에는 전혀 유용하지 않습니다.

변수의 경우 변수가 표현식이므로 ? 또는 : 를 변수 이름으로 사용할 수 있는 방법에 전혀 변경이 없습니다.

좋은 지적, @daxian-dbw; {...} 변수 이름 경계 모호성을 해결하는 데 사용할 수 있다는 것을 잊었으므로 코드 골퍼가 ${isWindows}?${number}:47 와 같은 것을 사용할 수 있다고 생각합니다.

지금 닫을 수 있습니까?

#10367을 통해 닫기