Powershell: 제안 : null 통합, null 조건부 액세스 (null-soaking), null 조건부 할당 구현

@ mklement0 두 번째 샘플은 "?"없이 디자인 된 것 같습니다.
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})

한 사람이 모두 더럽고 부끄럽다 고 느끼게 만듭니다.

오늘이 일을 해결하기 위해 나 자신을 발견했습니다.

```파워 쉘
$ 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 }) 이어야하지만 $( ) 가 필요한 유일한 PowerShell 버전은 버전 1이었습니다. v2부터 다음을 수행 할 수 있습니다.

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

@bgshacklett $word=($null,'two')[$null -ne 'three'] 의미하지 않습니까?

이것이 6.1에서 6.2로 "Future"로 바뀌는 것은 조금 안타깝습니다.

@ TheIncorrigible1 아니요, 위에서 추가 한 내용을 복사하여 붙여 넣으면 $word 값이 "two"로 설정되어있는 것을 볼 수 있습니다. 이 Stack Overflow 답변에는 패턴을 처음 본 부분에 대한 자세한 내용이 있습니다.
https://stackoverflow.com/a/17647824/180813

Perlesque 해킹은 RIPE-DB 사용자 또는 조직 기록을 등록 및 / 또는 쿼리 한 shebang을 작성한 20 년 전 저에게 호소하지만, powershell에서 바라는 것은 동료들이 언어를 사용하도록 장려하는 것입니다. 그들에게 두려움을 심어주기보다는

내 리트머스 테스트는 다음과 같습니다. 새해 아침 3시에 태블릿을 통해 이것을 읽고 싶을까요? 우리가 몇 백만 달러를 잃고 있는지 전화로 울면서 전화를 끊는 동안.

(참고 : 이것은 내가 페이스 북에서 일하고 긴급한 유출에서 돌아와서 2 분 만에 네덜란드 인구보다 더 많은 사람들이 빈 자리를 차지했다고 말하기 전까지는 실제 경험에 대한 느슨한 과장 일뿐입니다. 그것은 내 코드가 아니었고, 실수는 매우 특정한 템플릿 케이스에 대한 C ++ 표준에서 return x 대 return (x)의 의미를 약간 변경 한 것이 었습니다. "2 분 안에이 코드를 읽으시겠습니까? 마감일, 방광이 가득 차고, 네덜란드 사람의 고양이 사진을 어깨에 걸치고있는 모든 막힘의 운명 ??? "이 멋지게 들리지 않았습니다.)

예. PS에는 대단한 트릭이 있거나 일회성 속기가 필요한 경우 몇 가지 깔끔한 트릭이 있습니다.

유지 관리 가능한 코드의 경우 이상적으로는 C #과 같은 명시적인 null 통합 연산자가 있어야합니다. 저에게 가장 큰 문제는-우리는 그것들을 위해 무엇을 사용합니까? ? 이미 별명이 붙을 Where-Object (I가 삭제 될 그것을 위해 싶지만만큼, 매우 일반적으로 사용이다). % 별칭은 ForEach-Object 이지만 모듈러스 연산을 방해하지는 않습니다. 따라서 이론적으로는 적어도 ? 가 null-coalescing 연산자가 될 가능성이 있습니다. 좋아; Where-Object 는 어쨌든 실제로 유효하지 않은 표현식에서만 해석됩니다.

@ vexx32 :

적어도 _syntactically_ ?? 는 괜찮을 것입니다. _expression_ 모드에 대해 이야기하고 있기 때문입니다. 반면 ? 는 [별칭] 명령으로 _argument_ 모드에서만 인식됩니다.
심볼의 재사용이 혼동을 유발하는지 확실하지 않지만 심볼이 다른 맥락에서 이중 역할을하는 것은 이번이 처음은 아닙니다.

놀랍게도, null-soaking에 ?. 및 ?[] 를 사용하는 것은 기술적으로 큰 변화가 될 것입니다. PowerShell은 현재 ? 를 변수 이름의 초기 문자가 아닌 문자로 허용하기 때문입니다.

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

그러나 이것이 Bucket 3 : 가능성이없는 회색 영역 변경으로 간주되기를 바랍니다.

나는 내가 누군가 사용을 본 적이 말할 수 없다? 변수 이름으로 ... 나도 마찬가지입니다. 왜냐하면 잘못 읽을 가능성이 있기 때문입니다. 그러나 네, 완벽하게 사용할 수 있기를 바랍니다.

이 문제를 제기하는 것이 조금 늦었다 고 생각하지만 Bash는 매개 변수 대체 기능 ( https://www.tldp.org/LDP/abs/html/parameter-substitution.html )을 사용하여이 문제 (및 일부 다른 경우)를 처리했습니다

그것으로 할 수있는 일이 엄청나게 많기 때문에 배우는 것은 곰이 될 수 있지만, 믿을 수 없을만큼 강력합니다. PowerShell이 ​​변수와 함께 중괄호를 사용하는 방식으로 인해이 정확한 표기법을 사용하는 것이 불가능하거나 언어의 일반적인 느낌에 꼭 맞지 않을 것이라는 것을 이해하지만 유용한 데이터 포인트처럼 보입니다.

@bgshacklett :

예, 매개 변수 대체는 강력하지만, 안타깝게도 _learn_뿐만 아니라 _remember_에도 부담이됩니다.

따라서 Bash의 _features_는 종종 흥미롭지 만 _syntactic form_은 종종 신비하고 기억하기 어렵고 PowerShell에 적합하지 않습니다.

_Brace의 expansion_ (예를 들어, a{1,2,3} 에서 bash 로 확장 a1 a2 a3 ) 표현력 내가 PowerShell에서보고 싶어요 흥미로운 기능의 예이지만, PowerShell을 맞는와 구문-# 4286 참조

완전히 동의 해. 이 문제가 정확한 해결책이 아닌 다른 곳에서 어떻게 해결되었는지에 대한 예로서 더 많이 언급했습니다.

고려해야 할 다른 연산자가 하나 있습니다.

$x ?= 12

설정되지 않은 경우 $x 설정됩니다 (존재하지 않음). 이것은 전통적인 언어에서는 흔하지 않지만 쉘, 메이크 도구 등과 같은 (동적으로 범위가 지정된) 언어의 "초기화 패턴"의 일부입니다. 사용자가 기본값을 지정하지 않은 경우 기본값을 설정하는 스크립트를 사용하는 것이 매우 일반적입니다. . (사실 매개 변수 이니셜 라이저는 매우 널리 퍼져 있습니다.)

이것을 속성으로 확장 :

$obj.SomeProperty ?= 13

존재하지 않는 경우 개체에 SomeProperty 메모 속성을 추가하고 초기화합니다.

그리고-재미로- -or 사용하여 변수 초기화에 대한 또 다른 변형 :

$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-soaking (?.)은 간결한 방식으로 $ null을 무시하려는 명시적인 의도를 알리는 데 유용합니다.

. 신호가 이미 비 엄격 모드에 있지 않습니까? 엄격 해 지길 원했다면 먼저 확인하지 않음으로써 .Name 존재 여부를 먼저 확인할 수 있었으며, 확인이 중요하지 않다는 명시적인 의도를 이미 표시 한 것입니다.

StrictMode는 존재하지 않는 속성에 액세스 및 반환 목적이있는 경우 $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_에 관한 것이며 속성 존재 여부를 확인하는 것은 동일한 패턴을 따릅니다.

동적 스크립팅 언어가 정적으로 형식화 된 컴파일 된 언어가 _compile time_에보고하는 오류를 찾는 데 가장 근접한 것으로 생각합니다.

그게 뭐야. 이미 비 엄격 모드에있는 신호입니까? 엄격하게하고 싶었다면 먼저 존재하는 .Name을 확인할 수 있습니다.

예,하지만 엄격하지 않은 모드에서는 앞서 언급 한 존재 확인을 무시하고 수동 테스트는 분명히 상당히 번거롭고 내장 기능보다 항상 느립니다.

먼저 확인하지 않음으로써 확인이 중요하지 않다는 명시적인 의도를 이미 표시 한 것입니다.

요점은 Set-StrictMode -Version 2 이상이면 다음을 얻을 수 있다는 것입니다.

• 멤버 존재 확인의 이점 _ 기본적으로 _
• 옵트 아웃 옵션, _ 주문형, 간결하게 _ .?

스크립트 상단에 # StrictMode SkipMemberExistenceCheck 선언을하거나 일반적으로 unstrict code 블록을 나타내는 이스케이프 해치 속성을 가질 수 있습니다.

관련 : Set-StrictMode 의 현재 동적 범위 지정이 문제입니다. _lexical_ 엄격 모드를 구현하기위한의 RFC 초안을 @lzybkr 참조 : 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()   -> ____  ?

즉, ?. 는 non-strictmode의 속성 조회에 대해 . 와 동일하게 작동하지만 non-strictmode의 메서드 호출에 대해서는 . 와 다르게 작동하여 미묘한 차이를 만듭니다. 드롭 인 교체. 이것은 ?. 를 사용할 때 메소드가 호출되었는지 또는 아무 일도 일어나지 않았는지 알 수있는 방법이 전혀 없다는 것을 의미합니까? 속성은 getter 메서드에 의해 뒷받침 될 수 있지만 getter가 내부 상태를 변경하지 않는 것이 DotNet의 관례라고 생각하지만 메서드 호출이 상태를 변경하는 것은 정상이라고 생각합니다. ?. 를 사용하면 개체의 상태를 변경했는지 알 수 없습니까?

?? 에서 왼쪽의 표현식에서 PropertyNotFoundException 및 MethodNotFound 예외를 직접 처리 할 수있게하고 (메소드 내부에서 발생하는 다른 예외는 제외) ?? 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_ 액세스의 경우-참조)가 필요하지 않습니다. 다음 코멘트 re _method calls_ 및 _indexing_).

  • _personal_ 메모에서 : 저는 _variable_ 이름의 오타를 피하기 위해 Set-StrictMode -Version 1 를 사용하는 경향이 있지만, 주로 # 2798로 인해 -Version 2 이상이 너무 귀찮습니다. 이 제안).

• (a) 속성 이름의 철자가 틀리지 않았는지 및 / 또는 (b) 코드가 의도하지 않은 데이터 유형에서 실수로 작동하지 않는지 확인하려면 엄격 모드를 버전 2 이상으로 설정하십시오. .

  • 실제로, _ 현재 _는 이러한 수표를 _ 요청시 _ _ 선택 해제 _하는 것이 번거 롭습니다.
  • 이것이 바로 여기에서 null 조건부 액세스를 도입하는 이유입니다. 주문형 옵트 아웃을 _ 쉽게 _ 만드는 것입니다.

멤버의 존재 여부를 명시 적으로 테스트하는 것은 실제로 적용되는 엄격 모드에 관계없이 필수적 일 수있는 별도의 사용 사례입니다.

OP가 다루지 않는 _method calls_의 경우 :

_ 메소드 호출 _ (예 : $varThatMayBeNull.Method() ) 및 _indexing_ (예 : $varThatMayBeNull[$index] )은 엄격 모드가 꺼져 있거나 버전 1에서도 도움이 될 수있는 두 가지 경우입니다. 두 경우 모두 현재 _invariably_ 액세스되는 값은 $null 입니다.

구문은 메서드의 속성- $varThatMayBeNull?.Method() -와 동일하고 인덱싱- $varThatMayBeNull?[$index] -의 경우 C #과 유사합니다.

_Update_ : 인덱싱에 대한 두 번째 측면이 있습니다. 즉, 변수가 null이 아니지만 지정된 인덱스의 요소가 존재하지 않는 경우 (예 : $arr = 0,1; $arr[2] ). Strict 모드 버전 2 이하에서는 $null 로 평가되지만 버전 3 이상에서는 오류가 발생하며이 오류도 옵트 아웃 할 수 있으면 좋을 것입니다. 그러나이 경우의 구문은 문제를 제시합니다. 업데이트 된 OP를 참조하세요. 현재 아마도 어색한 [...?] 제안합니다.

그리고 예, 저는 이러한 액세스를 기본적으로 $null 로 설정합니다. 메서드의 경우에도 마찬가지입니다. 다시 말하지만, 액세스중인 개체가 $null 이면 아무 작업도하지 않아도된다는 _explicitly_ 신호를 보냅니다. 그러한 배열 요소가 존재하지 않는 경우.

C #에는 두 번째 의미에서 null 조건부 인덱싱이 없습니다.

그것은 당신이 제안하는 방식과는 달리 null 조건부 인덱싱을 가지고 있습니다. C #은 일반적인 "인덱스를 null 배열 / 컬렉션으로"문제를 우회하고 null을 반환하는 array?[0] 를 허용합니다 (적어도 ...).

하지만 네, 이것이 좋은 생각이라는 데 동의합니다. 예외 처리를 거치지 않고 코드를 매우 명확하고 간결하게 유지합니다.

@ vexx32 , 즉 null 조건부 인덱싱의 _one_ 측면입니다. array array?[0] 이 null 인 경우 인덱싱 작업이 무시됩니다. C #도 마찬가지입니다.

널 (null) 조건부 색인의 _other_ 측면에 대해 이야기 : (_also_ 갱신) : I이었다 경우 경우 array 에서 array?[0] _not_입니다 null 하지만 인덱스에서 _The 요소 0 _ 존재하지 않습니다.

내가 아는 한 C #에서 무시할 수없는 것은 후자이지만 유용 할 것이라고 생각합니다.

이 두 가지 측면에 고유 한 이름을 부여하는 용어를 생각할 수 있습니까?

다른 자바 스크립트 문제의 코드는 $_.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?] ?

최소한 개념적으로는 분리 할 가치가있는 측면을 통합했음을 알고 있기 때문에 먼저 한 발 물러서야합니다.

• C #에서와 같이 _Null-value_- 조건부 멤버 또는 인덱스 액세스 :

  • 액세스되는 값이 $null 이면 해당 멤버 또는 인덱스에 대한 액세스 시도를 무시하고 $null 평가됩니다.

• _Member-existence_- 조건부 멤버 또는 인덱스 액세스, PowerShell 관련 :

  • 액세스중인 값이 _non- $null _ 인 경우 존재하지 않는 _members_ (속성, 메서드 호출, 인덱싱)에 대한 액세스 시도를 무시합니다.

참고 : 간결함을 위해 여기서는 _member_를 다소 느슨하게 사용하여 점 표기법이 아닌 _indexing_으로 액세스되는 컬렉션 인 개체의 _elements_도 포함합니다.

코드에 오타가 없다고 확신하는 경우-반드시 기본 동작 (엄격 모드 OFF)을 활용하십시오. 그러면.? (속성 액세스 용

@ mklement0 나는 당신이 " 엄격 모드를 사용하여 자신의 코드를 개선하기 위해 " 다른 사람이 strictmode에서 내 코드를 실행할 수 있습니다. 어떤 변경 사항이 그들에게도 효과가 있습니까? "그리고 그것은 저를 다른 추론으로 이끌고 있습니다. ?. 를 사용하면 . 대신 사용하는 것이 매우 편리 할 것이며 코드도 엄격 모드에서 작동하여 어디서나 습관적으로 사용할 수 있습니다. 나는 아무것도 잃지 않고 호환성을 얻습니다. 더 많은 경우에 "작동"하기 때문에 모든 PowerShell 코드가 그런 식으로 작동하지 않을까 두렵습니다.

그러나 이것은 비 엄격 모드에서 실패한 메서드 호출 조회를 침묵시키고 엄격 모드에서 실패한 속성 조회를 침묵시키기 때문에 드롭 인 대체가 아닙니다. 이것은 엄청나게 일반적인 작업 인 멤버 조회에 묘한 뉘앙스를 추가합니다. 엄격한 모드 검사를 통해 상용구를 더 쉽게 만들고자하는 사람에게는 도움이되지 않습니다. 복잡성이 추가되기 때문에 충분한 상황에서 충분한 사람들을 돕지 않습니다. 그리고 코드의 호환성을 높이는 것은 너무 편리합니다. "원하지 않으면 무시"하는 것이 충분히 강력하다고 생각하지 않습니다.

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 "_ 한 사람이 자신의 코드를 개선하기 위해 엄격 모드를 사용하고 있습니다 _"라는 관점에서 논의하고 있다고 생각합니다. 그리고 "_ 다른 사람이 strictmode에서 내 코드를 실행할 수 있습니다. 어떤 변경으로 인해 코드가 작동하게 될까요?" _ "

"set -euo pipefail"(bash strict 모드)에 해당하는 것에 대해 이야기하고 있습니까?

a- 변수 조회 제한 (멤버 조회에 대한 간단한 null 검사가 나쁜 일이라고 생각하는 이유는 알 수 없지만 실제 멤버 조회는 if (result is null) 보다 훨씬 비쌉니다)
b- 범위 / 코드 블록에서 [Strict] 를 사용하여 파서에게이를 처리하도록 지시합니다.
c- 엄격 성은 범위를 기반으로합니다. 엄격함으로 표시되지 않은 코드는 엄격하지 않습니다.

사용할 때 실패하는 엄격한 코드를 작성하면 우리 중 한 명이 실수를 한 것입니다. 내가 테스트 한 적이없는 코드에서 누락 된 변수를 참조했거나 내 함수에 전달되지 않은 변수의 존재에 따라 잘못 설계된 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()] 속성은 범위 제한 방식으로 엄격 모드를 구현하는 _awesome_ 방법입니다. 그것은 엄격 모드 문제에 대한 다른 이슈 스레드에서 언급되어야합니다. 나는 그것을 파고 여기로 다시 링크 할 것입니다.

@ TheIncorrigible1 " 어떻게 이러한 것들을 침묵합니까? "비 엄격 모드에서 $null.x 는 침묵하고, $null.x() 는 예외입니다. ?. 에서 설명한대로 $null?.x 는 무음이고 $null?.x() 는 무음입니다.

따라서 예외가 발생하는 엄격 모드를 제외하고는 C #의 ?. 처럼 작동하는 . 가 있습니다. 그런 다음 C #의 ?. 와 같은 엄격 모드에서 작동하는 ?. 가 있고 PowerShell의 . 처럼 엄격하지 않은 모드에서 작동하지만 PowerShell의 . 와는 다르게 작동합니다 . . 얼마나 끔찍한 조합입니까 (그리고 ?. 가 더 많은 시나리오에서 분명히 더 좋고 더 유용한 조합).

이전에 예외 처리 및 null 검사로드를 작성해야합니다. 대신 $prop = $item?.Method().PropIwant ?? 'PropActionFailed'

메서드 호출이 throw되거나 $ 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'탈출 해치가 있기 때문에 고통을 겪을 필요가 없습니다. 지금". Ick.

사용할 때 실패하는 엄격한 코드를 작성하면 우리 중 한 명이 실수를 한 것입니다.

회원 조회에 대한 간단한 null 검사가 나쁜 일이라고 생각하는 이유는 모르겠지만 실제 회원 조회는 if (result is null)보다 훨씬 비쌉니다.

나는 그것이 나쁘다고 생각하지 않는다. PS non-strictmode는 이미 그렇게하고 있으며, 제안 된 ?. 대한 바람직한 대안이 될 것이라고 생각한다. 매우 다르고 더 많은 상황에서 유용하다.

그러나 PS에서는 C #이 할 수없는 일을 할 수 있습니다.

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

엄격하지 않은 모드에서는 예외가 없습니다. 숫자를 변경하고 시간이 얼마나 걸리는지 확인하십시오. 성능과 임의의 객체로 인덱싱하기 위해 백그라운드에서 작동해야한다고 생각하는 방식으로 판단하면 편의를 위해 실제로 ~ 100,000 개의 예외가 발생하고 침묵하는 것 같습니다. PS는 항상 "가능한 한 빨리해야하고, 사용자에게 불편을 끼쳐 야한다"는 선택을하는 것은 아닙니다. 저는 그 점이 마음에 듭니다.

@HumanEquivalentUnit 모든 언어에는 경력에 사용하지 않을 수있는 많은 기능이 있으며 스타일이 마음에 들지 않으면 해당 기능을 사용할 필요가 없습니다. 왜 엄격 모드를 끄는 지 모르겠습니다. 그것은 스크립트에서 좋은 관행이므로 언어가 문제를 삼키는 것보다 의식적으로 문제를 처리하고 있습니다 (그리고 본질적으로 모든 곳에서 암시 적 빈 catch 블록을 가짐). 다시 말하지만, 당신은 아직도 기능을 사용하지 오신 것을 환영합니다 (예를 들어, 내가 사용한 적이 Out-Default ).

또한 연산자는 ? 가 아니라 ?. . 인덱스 액세스에서도 작동합니다.

계속해서 추가 논의를위한 토대를 마련하기 위해 기존의 엄격한 모드가 null 값 조건부 및 멤버 존재 조건부 액세스에 어떻게 영향을 미치는지 요약하겠습니다 ( 위에 소개

아래 열은 Set-StrictMode 설정을 나타내고 열 값은 다음을 나타냅니다.

• 👍 ... 허용
• 🚫 ... 금지됨 (명령문 종료 오류 발생)

제쳐두고 : 오류가 _script_-terminating이 아니라 _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_-conditional access- $obj is non- $null 이지만 액세스중인 멤버 / 요소가 존재하지 않습니다.

구성 | -오프 | -버전 1 | -버전 2 | -버전 3+
---------- | ---- | ---------- | ---------- | ------------
$ obj.Prop | 👍 | 👍 | 🚫 | 🚫
$ obj [42] (인덱싱 가능) | 👍 | 👍 | 👍 | 🚫
$ obj [42] (인덱싱 불가능) | 👍 | 👍 | 🚫 | 🚫
$ obj.Method () | 🚫 | 🚫 | 🚫 | 🚫

본질적으로 인덱싱 할 수있는 객체 (예 : 배열)는 -Version 2 도 존재하지 않는 요소에 대한 액세스를 허용하는 반면, PowerShell이 ​​컬렉션과의 통합 처리를 위해 인덱싱 기능을 제공하는 스칼라는 그렇지 않습니다.

null-soaking ( null-conditional 또는 C #의 Elvis ) 연산자는 StrictMode Latest에서 실행 중이거나 존재하지 않을 수있는 속성에 액세스하려고 할 때 거의 필수입니다. 현재 다음과 같은 멍청한 속임수에 의지해야합니다.

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

당신이 _really_ 그냥 쓸 수 있어야 할 때 :

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

제발, 만약 당신이이 제안에서 오직 속성에 대해서만 null-conditional을 얻을 수 있다면, 그것은 많은 사람들을 그렇게 많은 고통을 덜어 줄 것입니다.

나는 이것을보기 시작했고 몇 가지 문제를 발견했습니다.

?? 및 ?= 고려해보십시오.

$x ?= 1 및 $x ?? 1 은 간단 해 보입니다. 하지만 연산자이므로 $x?=1 및 $x??1 를 지원해야합니다.

문제는 $x? 및 $x?? 모두 PowerShell에서 변수 이름의 유효성을 검사한다는 것입니다. 명확하게하는 유일한 방법은 ${x}?=1 및 ${x}??1 입니다.

그리고 조건부 멤버 액세스 ?. 및 ?[] 경우 ${x}?.name 및 ${x}?[0] 이 있어야합니다.
이러한 경우 $x ?.name 및 $x ?[0] 는 지원되지 않습니다.

다른 옵션은 주요 변경 사항 을 도입하고 변수 이름에 ? 를 전혀 허용하지 않는 것입니다.

어떻게 생각해? 뿡 빵뀨

/ cc @rjmholt @ daxian-dbw @JamesWTruher

나는 특별히 _liked_하지 않았고 ? 이 유효한 변수 이름 인 이유를 이해하지 못했습니다. $Safe? 와 같은 이름의 문이 열리는데, 어쨌든 $IsSafe 로 쓸 때 일반적으로 더 명확하고 덜 어색합니다.

그 변화는 아마 오랜 시간이 걸렸다 고 생각합니다.

$ Safe와 같은 이름의 문이 열립니다. 어쨌든 $ IsSafe로 작성하면 일반적으로 더 명확하고 덜 어색합니다.

흥미롭게도 나는 반대의 감정을 표현했다. 고전적인 Scheme / Ruby 전통입니다.

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

삼항 연산자가 ? 끝나는 변수와 제대로 작동하기 위해 연산자 주위에 공백이나 변수 이름 주위에 중괄호를 사용하는 것과 동일한 문제가 없었습니까?

이러한 연산자가 도입되면 PowerShell은 ? 끝나는 변수 이름을 사용하는 사용자가 $x?[0] 와 같은 구문에서 연산자의 일부로 ? 를 인식하는 우선 순위를 지정할 것으로 예상합니다 $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

오늘은 구문 분석하지 않는 것이 조금 놀랍습니다 (왜 구문 분석하지 않습니까?). 그러나 이러한 속성의 경우 이름을 따옴표로 묶어야합니다.이 경우 따옴표 뒤에 삼항, null을 사용할 수 있습니다. -합체 등 연산자는 공백없이 잘 작동합니다. 이 구문은 ${x?}?.name 와 매우 유사하며 원하는 경우 이러한 변수 / 속성 이름을 사용할 수 있다는 입장에 동의하지만 이러한 이름은 삼항 또는 null과 함께 작동하려면 추가 구문이나 공백이 필요할 수 있습니다. -* 연산자.

@KirkMunro 사람들이 난해한 변수 이름을 원하는 경우 앞으로 변수 경계를 사용하는 것을

PowerShell 7의 사람들은 이미 열광적 일 가능성이 높으며 주요 변경 사항을 알고있을 것입니다. 그렇지 않은 사람들은 여전히 ​​<= v5.1을 사용하고 있으며 오랫동안 계속할 것입니다. msft가 Windows 10에서 제거 할 때까지 가능합니다 (절대 안 됨).

@KirkMunro 물론입니다.하지만 표준 허용 변수 문자에서 제거한다고해서 사용자가 ${Valid?} 를 변수 이름으로 사용하는 것을 막지는 않습니다. 그들은이 연산자들과 상관없이 그렇게해야하기 때문에, ? 가 변수 이름의 일부로 간주되는 _ 때때로 _ 오직 _ 만 _ 문자가되는 것보다는 일관성을 유지하는 것이 더 낫다고 생각합니다.

그것은 이미 획기적인 변화가 될 것입니다. 그리고 저는 다른 수준의 모호성을 도입하는 것보다 적어도 그것에 대해 일관성을 유지하고 끝까지가는 것이 최선이라고 생각합니다. 🙂

@adityapatwardhan 언어가 유효한 변수 문자로 ? 를 제거하는 것이 더 나을 것이라고 생각합니다. 스크립트 작성 프로세스에 많은 인체 공학을 추가하는 친숙한 구문에서 null-soak / coalesce 및 삼항 연산자를 쉽게 사용할 수 있습니다.

@KirkMunro 가 "우선 순위 파싱"을하는 것은 버그에 대한 열린 문처럼 들립니다.

@ TheIncorrigible1 : 제대로 구현되지 않으면 모든 코드가 버그의 문을 열 수 있습니다. 저는 PowerShell이 ​​변수 경계로 묶이지 않은 변수 이름을 구문 분석하고 ? 문자를 만날 때 PowerShell이 ​​삼항 또는 null- * 연산자로 실행되는지 식별하기위한 간단한 단일 문자 미리보기에 대해 이야기하고 있습니다. 그것은 복잡하지 않으며 다른 코드 변경보다 더 많은 버그의 문을 열지 않습니다.

PowerShell 7의 사람들은 이미 열광적 일 가능성이 높으며 주요 변경 사항을 알고있을 것입니다. 그렇지 않은 사람들은 여전히 ​​<= v5.1을 사용하고 있으며 오랫동안 계속할 것입니다. msft가 Windows 10에서 제거 할 때까지 가능합니다 (절대 안 됨).

@ TheIncorrigible1 : 그 진술에 대한 근거 / 증거는 무엇입니까? PowerShell 7은 미리보기로 제공되므로 현재는 매니아 만 사용합니다. 그것은 주어진다. 그러나 미리보기를 넘어서 PowerShell 7 이상이 회사에 필요한 매력적인 기능을 제공하는 동시에 필요한 기능을 지원하는 경우 해당 버전을 사용하게됩니다. PowerShell 7이 OS와 함께 설치된 경우 특히 그렇습니다. 애호가가 작용하는 유일한 요점은 PowerShell 7이 제공하는 기능에 대한 비즈니스 요구 사항이없는 조직에 있습니다.

그것은 이미 획기적인 변화가 될 것입니다. 그리고 저는 다른 수준의 모호성을 도입하는 것보다 적어도 그것에 대해 일관성을 유지하고 끝까지가는 것이 최선이라고 생각합니다. 🙂

@ 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 이상이 회사에 필요한 강력한 기능을 제공하는 동시에 필요한 기능을 지원하는 경우 해당 버전을 사용합니다. PowerShell 7이 OS와 함께 설치된 경우 특히 그렇습니다.

포츈 50 대에 근무하면서 일부 직원 기반이 수십만 명에 이르렀지만 OS의 기본 설정에서 벗어나는 것도 도전이었습니다 (예 : v5.x로 이동). Core를 채택한 곳은 아직 보지 못했습니다. 오히려 상호 호환성을 위해 Python으로 이동하는 것이 좋습니다. Windows 선택적 기능을 활성화하는 것도 매우 드문 작업이었습니다.

회사는 문제를 해결하기 위해 새로운 기술이나 언어 버전을 찾는 것보다 자신이 가진 것과 직원의 지식 기반을 가지고 일한다고 생각합니다. 일부는 v2에 영원히 머물며 삶을 극적으로 쉽게 만드는 Win10 / Server16 cmdlet을 결코 건드리지 않는 완벽한 콘텐츠 일 것입니다.

이 모든 것에 대한 나의 요점은 이러한 기능이 진공 상태가 아니라는 것입니다. 언어를보다 인체 공학적으로 만들면 사람들이 문제를 더 빨리 해결할 수있는 도구에 관심이있는 사람들이 더 많이 채택 할 수 있습니다. (참조 : C # 및 더 많은 / 더 나은 언어 기능으로 인기 증가)

? 끝나는 변수와 관련하여-자동 변수 $? .

@lzybkr 저는 $^ 및 $$ 대해 이미 존재하는 것과 같은 특수한 경우를 처리하는 가장 좋은 경우라고 생각합니다.

@lzybkr @ TheIncorrigible1 제가 기억하는 한, 모든 변수는 토크 나이저에서 명시 적으로 특수한 경우입니다. $^ _already_은 (는) 유효한 변수 이름이 아닙니다. 토크 나이 저는 표준 변수 이름을 찾기 시작하기 전에 모든 것에 대한 특별한 경우를 가지고 있습니다.

여기서 유일한 해결책은 ¿ .

$ silly? ¿ = 1

나는 스티브를 몰라, 나는 이것에 대해 interrobang 군중에 단단히 있습니다.

$silly?‽=1

@lzybkr- 내가 아는 한 $? $$ 및 $^ 는 특별한 방식으로 취급됩니다.

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

요약하면 다음 네 가지 옵션이 있습니다.

• 큰 변화-변수 이름에 ? 를 허용하지 않습니다.
• ?. 를 연산자로 선호합니다. 즉, ? 끝나는 변수 이름은 ${variablename} 구문을 사용해야합니다. 여전히 획기적인 변화입니다.
• 오래된 행동을 선호하십시오. 즉, ?. 및 ?[] , ${variablename}?.property 사용해야합니다. 주요 변경 사항은 없지만 새 연산자를 사용하면 서투르게 만듭니다.
• 새 연산자를 구현하지 마십시오.

나는 개인적으로 첫 번째와 마지막을 선호하지 않습니다.

이것은 주요 버전 변경입니다. 여기에서 이것이 바뀌는 것이 부당하지 않다고 생각합니다.

중요한 점은 Windows PowerShell을 대체 할 준비가되었음을 알리기 위해 메이저 버전이 증분된다는 것입니다. 즉, 손상이 아니라 호환성을 나타냅니다. 원래 발표에서 :

주 버전이 중대한 변경 사항을 적용한다는 것을 의미하지는 않습니다.

옵션 1과 2는 동일하지 않습니까? 아니면 변수 뒤에 널 통합 또는 삼항 연산자가없는 경우에도 ? 를 사용할 수 있습니까?

그렇다면 많은 역 추적없이 토큰 화 / 파싱 로직을 처리하는 데 많은 문제가있을 수 있다고 생각합니다. 이로 인해 변수가 ? 끝나는 경우 성능이 저하 될 수 있습니다.

내가 볼 수 있듯이 옵션 2가 일반적으로 선호되는 것처럼 보이므로 여기서 주요 변경을 꺼리는 것을 이해하지 못합니다. 그렇게하면 변수 이름을 묶지 않고는 사용할 수없는 시나리오를 도입하여 변수 이름에 ? 사용을 적극적으로 억제 할 수 있습니다.

내 생각에 이것은 주요 변경 사항이 진행됨에 따라 상당히 사소한 변경이라고 생각하며 변수 이름에 사용할 수있는 것과 사용할 수없는 것의 일관성이 깨지는 것은 아마도 더 나쁜 선택 일 것입니다.

이러한 것들은 거의 모든 상황에 적용되는 명확한 규칙이 있어야합니다. 현재 이것이 사실입니다. 우리는 여기서 물을 진흙탕으로 만들고 행동을 _less_ 명확하게 만들 것을 제안합니다. ? 포함하는 변수 이름이 일부 시나리오에서 사용하기가 더 어렵 기 때문에 덜 사용된다는 점을 제외하면 좋은 결과를 볼 수 없습니다. (효과적으로) 옵션 1로 바로 돌아갑니다. 기본적으로 거의 ... 그래서 지금은 쉬지 않고 모호한 행동을 피해야 할 특별한 이유가 없습니다.

@ vexx32 1과 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입니다. 적어도 한 번의 브레이킹 체인지는 미래로 파싱 할 수있는 방법의 불일치를 처리하는 것보다 훨씬 더 낫습니다.

그렇다면 많은 역 추적없이 토큰 화 / 파싱 로직을 처리하는 데 많은 문제가있을 수 있다고 생각합니다. 변수가?로 끝날 때 성능이 저하 될 수 있습니다.

나는 그 가능성에 대한 우려를 공유합니다. 가끔 토큰 분리 자로 ? 을 사용하는 것은 언어에서 들쭉날쭉 한 선처럼 느껴집니다.

그렇다면 많은 역 추적없이 토큰 화 / 파싱 로직을 처리하는 데 많은 문제가있을 수 있다고 생각합니다. 변수가?로 끝날 때 성능이 저하 될 수 있습니다.

구현 방법에 따라 다릅니다. 토큰 화 한 다음 백업 접근 방식보다는 예견 접근 방식을 취하는 한 괜찮습니다. 변수 이름에서 ? 를 발견하면 다음 문자가 무엇인지 미리 살펴보고 다음 항목에 따라 변수 토큰을 "포장"할 방법을 결정할 수 있습니다. 그것은 많은 문제가 아니며 역 추적이 필요하지 않거나 눈에 띄는 성능 저하를 초래해서는 안됩니다.

@ PowerShell / powershell-committee가 오늘 이것을 검토했으며 몇 가지 생각이 있습니다.

• 우리가 무엇을하든, 우리는 사람들이 변수 이름에 ? 를 얼마나 자주 사용하는지 알아보기 위해 스크립트 코퍼스를 분석 할 것입니다.
• 우리 중 일부는 변수 이름에 ? 를 사용하는 사용자가 고급 사용자 일 수 있다는 가설을 가지고 있습니다 (다른 사람이 확인하고 싶어 함). 발생할 수있는 잠재적 인 문제). 반면에 여기에 설명 된 기능을 사용하는 모든 사람은 약간 더 복잡한 구문 (예 ${foo}?.bar )을 이해할 수 있습니다. 따라서 경험이 부족한 사용자의 주요 변경 사항을 방지하기 때문에 옵션 3 을 선호합니다. (하지만 다시 한 번 첫 번째 글 머리 기호에 따라 유효성을 검사합니다.)
• @ daxian-dbw는 스크립터가 $foo 및 ${foo} 사용을 혼합 할 때 모든 변수 참조를 찾기 어렵게 만드는 것에 대해 좋은 지적을했습니다. 그러나 우리는이 문제를 도구 (예 : VS Code PowerShell 확장)에서 수정할 수 있으며 Vim과 같은 편집기를 사용하는

스크립터가 $ foo 및 $ {foo} 사용을 혼합 할 때 모든 변수 참조를 찾기가 더 어렵습니다.

AST가 중괄호를 보았는지 여부에 따라 변수 이름을 구별하는지 여부에 따라 다릅니다. PowerShell AST를 사용하는 모든 도구는 여기에서 중괄호에 문제가 없다고 생각합니다.

그러나 정규식의 경우 확실히 더 알고 있어야합니다. varname -> \{?varname\}?

@rjmholt 여기 에서 분석 ? 끝나는 고유 변수는 ~ 70 개뿐이었습니다.

고마워요, @mburszley- 저에게 Bucket 3 : 희박한 회색 영역 변경이 가능하며 {...} 가 필요한 사용자에게 부담을 주는 것은 $(...) 주변 exit $(...) 대한 불행한 필요성 과 병행 exit && 및 || 컨텍스트에서 exit / return / throw 문 .

그 문제에서 추론을 빌리려면 :

변수 이름 주위에 {...} 사용을 강제하면 ?. 사용할 수 있습니다.

• 신규 사용자는 {...} 대한 필요성을 기대하지 않으며 다음이 실패 할 때 _it_이 필요하다는 것을 반드시 알지 못할 것입니다 ( Set-StrictMode -Version 2 이상이 적용되지 않는 한 _undetected_ 일 수 있음) : $o = [pscustomobject] @{ one = 1 }; $o?.one

• 사용자가 {...} 의 필요성에 대해 _ 알고도 _ :

  • 직관에 반하는 필요성 때문에 때때로 사용하는 것을 잊을 것입니다.
  • 그들이 기억할 때,이 겉보기에 인위적인 요구 사항은 특히 {...} 를 입력하기 어렵 기 때문에 지속적인 좌절의 원천이 될 것입니다.

이 문제는 해결 된 것으로 표시되었으며 1 일 동안 활동이 없었습니다. 하우스 키핑 목적으로 폐쇄되었습니다.

@rjmholt , https://github.com/PowerShell/PowerShell/issues/10967#issuecomment -561843650에서 인용 :

기존의 유효한 구문을 구문 분석하는 방식을 깨지 않는 것이 올바른 방법이었습니다. 다시 말하지만, 우리가 소수의 야생 프로그램을 지원하기로 결정한 경우에만 변화가있는 것이 아닙니다. 우리는 전문가가 단점을 능가한다고 생각하는 경우에 수많은 주요 변경 사항을 적용했습니다. 그들 모두와 함께 또는 다른 사람들을 정당화하거나 정당화하지 않습니다). 문제는 토크 나이저 또는 파서의 일부 측면을 변경하면 두 개의 PowerShell 버전이 더 이상 일부 스크립트에 대해 동일한 AST를 생성하지 않으므로 두 개의 PowerShell이 ​​동일한 스크립트를 다르게 "볼"수 있다는 것입니다. 이는 우리가 같은 방식으로 구문을 읽을 수 없다는 것을 의미합니다. 따라서 가능한 문제를 해결하기 위해 작성할 수있는 PSScriptAnalyzer 규칙이 없습니다. PSScriptAnalyzer는 PowerShell 버전마다 다른 구문을 보게됩니다.

C #과 달리 PowerShell은 나중에 실행하기 위해 호환되는 형식으로 다른 구문을 미리 컴파일 할 수 없습니다. 즉, 구문 변경이 런타임에 연결됨을 의미합니다. PowerShell이 ​​구문을 중단하면 다른 버전에 대해 작동 할 수있는 스크립트의 수를 줄입니다. 즉, 사용자가 두 개의 스크립트를 작성해야하므로 셸과 스크립팅 언어에 심각한 문제가됩니다. PowerShell은 하나의 스크립트 내에서 논리의 모든 차이점을 극복 할 수있을만큼 동적이어야하지만 구문은 우리가 가지고있는 타협 할 수없는 정적 인 것입니다. 그리고 이전과 이후가 모두 유효한 구문을 변경하는 것은 특히 위험합니다.이를 감지하는 간단한 방법이 없기 때문에 경고가 없으며 두 환경에서 실행 한 후에도 사용자가 다른 동작이 발생했음을 알지 못할 수 있습니다.

일반적으로 이러한 변경은 매우 문제가 될 수 있으며 전문가가 단점을 능가하는 경우에만 이루어져야한다는 것을 이해할 수 있습니다. 중요한 요소는 기존 코드가 얼마나 많이 중단되는지입니다.

다른 버전에 대해 작동 할 수있는 스크립트의 수를 줄입니다.
사용자가 두 개의 스크립트를 작성해야 함을 의미합니다.

여기서는 _new_ 구문 기능 ( ?. )에 대해 이야기하고 있으므로이를 사용하는 정의 스크립트는 기존 버전과 호환되는 코드 경로를 제공하는 조건을 특별히 추가하지 않는 한 이전 버전에서 실행할 수 없습니다. 하지만 그럴 가치가없는 것 같습니다. 그러면 레거시 기능 만 고수 할 수 있습니다.

예, $var? 를 변수 이름으로 사용한 이전 스크립트에서 $var?.foo 의 해석은 깨질 수 있지만 다음과 같습니다.

• ? 는 {...} _로 묶지 않고 _ 식별자의 일부로 허용되지 않아야합니다.

• 그렇게 할 수 있다는 것은 예상치 못한 일이고 아마도 많은 사람들에게 _ 알려지지 않은 _ 것이므로, 그러한 변수 이름은 개인적인 경험으로 말하면 야생에서 매우 드물지만 @mburszley 의 분석은 더 확실한 증거를 제공합니다 .

  • Ruby조차도 _end_ 식별자에서 ? (및 ! ) 만 허용하고 _method_ 식별자 만 있습니다. 대부분의 Ruby 사용자는 다른 언어가 지원한다고 가정하지 _ 않아야한다는 것을 알고 있습니다. 똑같은 것.

그래서 실용적으로 말하면 :

• 대부분의 기존 코드는 영향을받지 않습니다. $var?.foo 와 같은 토큰은 발생하지 않습니다.

• 새로운 의미 체계로 $var?.foo 를 작성하면 예, 이전 버전에서 실행하면 엄격 모드가 적용되는 방식에 따라 다른 동작이 발생할 수 있습니다 (명백한 방식으로 중단되지 않음).하지만 _ 항상해야합니다. 어쨌든 의도 한대로 코드를 실행하는 데 필요한 최소 버전을 적용합니다 _ ( #requires -Version , 모듈 매니페스트 키).

대체로 저에게 이것은 버킷 3 변경의 분명한 경우입니다. 기술적으로 매우 적은 변경으로 기존 코드를 거의 깨뜨리지 않고 실질적인 이점을 제공합니다 (또는 반대로 예기치 않은 동작으로 인한 지속적인 두통 방지).

@ mklement0 우리는

@ SteveL-MSFT-# 11379를 참조하십시오.

여기있는 모든 사람들이 다시 거기에서 지원 (또는 헐떡이며, 비 지원)을 보여 주길 바랍니다.