함께 제공되는 RFC는 레이블이 지정된 반환 / 중단을 기반으로 desugaring에 대해 설명합니다. 우리도 그렇게됩니까 아니면 컴파일러에서 ? 및 catch 에 대한 특수 처리가 있을까요?

편집 : 레이블 반환 / 휴식은 ? 및 catch 과는 별개의 훌륭한 아이디어라고 생각하므로 대답이 '아니요'이면 별도의 RFC를 열 것입니다.

레이블이있는 반품 / 휴식은 순전히 설명을위한 것입니다.

2016 년 2 월 5 일 금요일 오후 3:56, Jonathan Reem [email protected]
썼다 :

첨부 된 RFC는 레이블이있는 반품 / 휴식을 기반으로 설탕 제거에 대해 설명합니다.
우리도 그것을 받고 있습니까 아니면 특별한 대우가 있습니까? 과
컴파일러에서 잡아?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/31436#issuecomment -180551605.

우리가 안정화되기 전에 해결하는 데 또 다른 해결되지 않은 문제는 계약 것입니다 impl s의 Into 여부 - 순종이 있어야 할 필요가 Into 사용으로도 올바른 특성입니다 여기에서 오류 업 캐스팅을 위해. (아마 이것은 다른 체크리스트 항목이어야합니까?)

림

레이블 반환 / 휴식은 훌륭한 아이디어라고 생각합니다. 아마도 별도의 RFC를 열 것입니다.

제발!

Carrier 특성의 주제에 대해 RFC 프로세스 초기에 작성한 특성의 요점 예가 있습니다.
https://gist.github.com/thepowersgang/f0de63db1746114266d3

구문 분석 중에 어떻게 처리됩니까?

struct catch {
    a: u8
}

fn main() {

    let b = 10;
    catch { a: b } // struct literal or catch expression with type ascription inside?

}

@petrochenkov 음, 정의는 구문 분석에 영향을 줄 수 없지만 { , : 이후의 두 번째 토큰을 기반으로하는 예견 규칙이 여전히 있다고 생각합니다. 구조체 리터럴로 구문 분석됩니다.

또한

let c1 = catch { a: 10 };
let c2 = catch { ..c1 }; // <--

struct catch {}
let c3 = catch {}; // <--

+ https://github.com/rust-lang/rfcs/issues/306 (언제!) 구현 된 경우.
구조체 리터럴 외에 충돌이없는 것 같습니다.

위의 예가 주어지면 가장 간단한 솔루션 (평소처럼)입니다. 항상 표현식 위치에서 catch { 를 catch 블록의 시작으로 취급합니다. 어쨌든 구조를 catch 라고 부르는 사람은 없습니다.

catch 대신 키워드를 사용하면 더 쉬울 것입니다.

다음은 키워드 목록입니다. http://doc.rust-lang.org/nightly/grammar.html#keywords

@bluss 그래, 나는 그들 중 누구도 훌륭하지 override 는 가까운 유일한 사람인 것 같다. 또는 do 사용할 수 있습니다. 또는 조합, 비록 내가 즉시 좋은 것을 보지 못하더라도. do catch ?

do 은 IMO에 가까운 것처럼 보이는 유일한 것입니다. do 접두사가있는 키워드 수프는 언어의 다른 부분과 비슷하지 않은 약간 불규칙한가요? while let 도 키워드 수프입니까? 익숙해지면 이제 괜찮다고 느껴집니다.

? 사용을위한 포트 try! ?

? try! 대신 Result 반환 경로를 얻으려는 사용 사례를 허용합니다. try! 하면 매우 간단합니다. 파일 시작 부분 (또는 lib / main.rs)에서 매크로를 재정의하기 만하면됩니다.

macro_rules! try {
    ($expr:expr) => (match $expr {
        Result::Ok(val) => val,
        Result::Err(err) => {
            panic!("Error occured: {:?}", err)
        }
    })
}

Result 반환 경로에서 try! 의 첫 번째 발생부터 패닉 스택 추적이 발생합니다. 당신이 할 경우 사실, try!(Err(sth)) 대신의 오류 발견하는 경우 return Err(sth) , 당신도 전체 스택 추적을 얻을.

그러나 그 트릭을 구현하지 않은 사람들이 작성한 외부 라이브러리를 디버깅 할 때는 체인의 어딘가에서 try! 사용에 의존합니다. 이제 라이브러리가 하드 코딩 된 동작으로 ? 연산자를 사용하면 스택 추적을 얻는 것이 거의 불가능합니다.

try! 재정의가 ? 연산자에도 영향을 미치면 멋질 것입니다.

나중에 매크로 시스템에 더 많은 기능이 추가되면 당황 할 수도 있습니다! 특정 유형에만 해당됩니다.

이 제안에 RFC가 필요한 경우 알려 주시기 바랍니다.

이상적으로 ? 만이 아니라 대체 할 수있는 능력에 의존하지 않고, 직접 스택 추적 지원을 제공하도록 확장 할 수 try! . 그러면 모든 곳에서 작동합니다.

스택 추적은 하나의 예일뿐입니다 (매우 유용한 것으로 보이지만).
Carrier 특성이 작동하도록 만들어지면 그러한 확장을 포함 할 수 있습니까?

2016 년 2 월 7 일 일요일 오후 4:14, Russell Johnston [email protected]
썼다 :

이상적으로? 스택 추적 지원을 직접 제공하도록 확장 할 수 있습니다.
try!를 재정의하는 기능에 의존하지 않고 그런 다음 작동합니다
어디에나.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/31436#issuecomment -181118499.

추측하고 싶지는 않지만 몇 가지 문제가 있지만 작동 할 수 있다고 생각합니다.

Result<V,E> 값을 반환하는 코드가있는 일반적인 경우를 고려하십시오. 이제 Carrier 특성의 여러 구현이 공존 할 수 있도록해야합니다. E0119 로 실행되지 않으려면 모든 구현을 범위를 ? 연산자를 사용할 때 사용자는 원하는 항목을 가져와야합니다. 이행.

이를 위해서는 디버그를 원하지 않는 사람이라도 ? 사용할 때 원하는 특성 구현을 가져와야하며 미리 정의 된 기본값에 대한 옵션이 없습니다.

모든 유형이 경계를 벗어난 Result<V,E> 대해 사용자 정의 Carrier 구현을 수행하려는 경우 E0117 도 문제가 될 수 있으므로 libstd는 이미 Carrier 의 구현 세트를 제공해야합니다. 가장 많이 사용되는 사용 사례의 panic! 구현 등).

매크로를 통해 재정의 할 수있는 가능성은 원래 구현 자에 대한 추가 부담없이 더 큰 유연성을 제공합니다 (원하는 구현을 가져올 필요가 없음). 하지만 Rust에는 이전에 매크로 기반 연산자가 없었으며, catch { ... } 가 작동해야하는 경우 매크로를 통해 ? 를 구현하는 것이 불가능하다는 것을 알 수 있습니다. return_to_catch , throw , RFC 243에서 사용되는대로 매개 변수로 break 레이블이 지정됨).

Err 반환 경로를 사용하여 Result 스택 트레이스를 얻을 수있는 설정은 괜찮습니다. 파일 상단에서 매우 적은 양의 코드 만 수정하면됩니다. 또한이 솔루션은 Err 유형이 구현되는 방법 및 위치와 무관하게 작동해야합니다.

자전거 흘리기에 차임 : catch in { ... } 은 꽤 멋지게 흐릅니다.

catch! { ... } 은 또 다른 backcompat 선택입니다.

또한 이것이 변경 될 것으로 기대하지는 않지만, 유형 지정이 $i:ident : $t:ty 깨는 것과 같은 방식으로 $i:ident ? 받아들이는 다중 암 매크로를 깨뜨릴 것이라는 점에 유의하세요.

이전 버전과의 호환성을 과도하게 사용하지 말고 { 다음에 catch 를 처리하십시오 (아마도 표현식 위치에서만 가능하지만 호환성 측면에서 많이 변경되는지 확실하지 않습니다).

또한 구조체 리터럴을 포함하지 않는 몇 가지 가능한 문제를 상상할 수 있습니다 (예 : let catch = true; if catch {} ); 그러나 나는 추악한 구문보다 사소한 변경을 선호합니다.

어쨌든 새 키워드를 추가하는 데 필요한 것이 없습니까? 새로운 구문에 대해 일종의 from __future__ 옵트 인을 제공 할 수 있습니다. 또는 명령 줄 / Cargo.toml에서 rust 언어 버전 번호를 지정하십시오.
장기적으로는 이미 예약 된 키워드로만 작업 할 수 있을지 의심 스럽습니다. 문맥에 따라 키워드가 각각 세 가지 다른 의미를 갖기를 원하지 않습니다.

나는 동의한다. 이것은 이것이 나온 첫 번째 RFC도 아닙니다 (https://github.com/rust-lang/rfcs/pull/1444가 또 다른 예입니다). 나는 그것이 마지막이 아닐 것으로 예상합니다. (또한 https://github.com/rust-lang/rfcs/pull/1210의 default , 제가 ​​선호하는 RFC는 아니지만) 추가 할 방법을 찾아야한다고 생각합니다. 새로운 경우마다 문법을 임시로 해킹하는 방법을 알아내는 대신 정직한 키워드를 사용합니다.

1.0 이전에 여러 키워드를 예약하지 않았다는 전체 주장이 언어에 새 키워드를 역 호환 적으로 (아마도 명시 적으로 옵트 인하여) 추가하는 방법을 확실히 도입 할 것이라는 것이 아니 었습니까? 지금이 좋은 시간이 될 것 같습니다.

@japaric 예전의 PR을 되 살리고 이것을 받아들이는 데 관심이 있습니까?

@aturon 내 구현은 try!(foo) 과 같은 방식으로 foo? 를 간단히 desugared했습니다 . 또한 메서드 및 함수 호출에서만 작동했습니다. 즉 foo.bar()? 및 baz()? 작동하지만 quux? 및 (quux)? 작동하지 않습니다. 초기 구현에서 괜찮을까요?

@japaric 메소드와 함수 호출로 제한 한 이유는 무엇입니까? 일반적인 접미사 연산자로 파싱하는 것이 더 쉬울까요?

메서드와 함수 호출로 제한 한 이유는 무엇입니까?

? 확장을 테스트하는 가장 쉬운 방법

일반적인 접미사 연산자로 파싱하는 것이 더 쉬울까요?

아마

@japaric 아마 전체 접미사 연산자로 일반화하는 것이 좋지만 ( @eddyb 이 제안한대로) 간단한 탈당으로 ? 를 설정 한 다음 나중에 catch 를 추가하는 것이 좋습니다.

@aturon 좋아, 아무도 나를 이길 수 없다면 다음 주까지 postfix 버전을 살펴볼 것입니다 :-).

# 31954에서 내 PR을 업데이트 / 업데이트했습니다. :-)

스택 추적 제공에 대한 지원은 어떻습니까? 계획된 건가요?

나는 +1 남자가되는 것이 싫지만, 스택 트레이스는 과거에 내 시간의 좋은 덩어리를 절약했다. 디버그 빌드에서, 오류 경로에 도달하면? 연산자는 결과에서 Vec에 파일 / 줄을 추가 할 수 있습니까? Vec도 디버그 전용 일 수 있습니까?

그리고 그것은 노출되거나 오류 설명의 일부로 바뀔 수 있습니다.

Option<Result<T, E>> 반환하는 반복기 내부에서 try! / ? 을 (를) 사용하려는 상황이 계속 발생합니다. 불행히도 현재는 실제로 작동하지 않습니다. 캐리어 특성이이를 지원하기 위해 오버로드 될 수 있는지 아니면보다 일반적인 From 로 들어갈 수 있는지 궁금합니다.

@hexsel 나는 정말로 Result<> 유형이 디버그에서 명령어 포인터의 vec를 전달하기를 바랍니다. 추가 할 것입니다. 그런 식으로 DWARF 정보를 사용하여 읽을 수있는 스택 추적을 구축 할 수 있습니다.

@mitsuhiko 하지만 어떻게 Result 를 만들고 패턴 매칭 할 수 있을까요? enum atm입니다.

에 대해서는 Option 포장, 나는 당신이 원하는 생각 Some(catch {...}) .

현재, 내 습관이 지금하는 것입니다 try!(Err(bla)) 대신 return Err() 내가 하나에 나중에 시도 매크로를 재정의 할 수 있습니다 그래서, 그 패닉, 백 트레이스를 얻기 위해서이다. 그것은 나에게 잘 작동하지만 내가 다루는 코드는 매우 낮은 수준이며 대부분 오류가 발생합니다. Result 를 반환하는 외부 코드를 사용하는 경우 여전히 ? 를 피해야합니다.

@eddyb 다른 방법으로 조작해야하는 것 외에도 숨겨진 값을 전달하려면 언어 지원이 필요합니다. 다른 방법으로 할 수 있을지 궁금했는데 어떻게되는지 모르겠어요. 유일한 다른 방법은 추가 데이터를 포함 할 수있는 표준화 된 오류 상자 였을 것입니다. 그러나 상자 오류가있을 필요가 없으며 대부분의 사람들이이를 수행하지 않습니다.

@mitsuhiko Error 트레이 트와 TLS에 대한 새로운 (기본) 메서드를 생각할 수 있습니다.
후자는 때때로 살균제에 의해 사용됩니다.

@eddyb 는 결과를 식별 할 수 있고 상자에

@mitsuhiko TLS? 실제로는 값별로 오류를 비교할 수 있어야합니다.

또는 유형별로 ( From 입력 및 출력 연결 포함) 스택 추적을 원하는 동시 오류 수를 동시에 전파해야하는 경우가 있습니까?

더 간단한 솔루션이 작동 할 때 개인적으로 Result -특정 컴파일러 해킹을 추가하는 것에 반대합니다.

@eddyb 오류가 스택 위로 전달됩니다. 당신이 원하는 것은 그것이 시작되는 곳뿐만 아니라 모든 스택 수준의 EIP입니다. 또한 오류는 a) 현재 비교할 수 없으며 b) 동일하게 비교한다고해서 동일한 오류라는 의미는 아닙니다.

스택 추적을 원하는 동시 오류 수를 동시에 전파해야합니다.

모든 오류가 포착되어 다른 오류로 다시 발생합니다.

더 간단한 솔루션이 작동 할 때 개인적으로 결과 별 컴파일러 해킹을 추가하는 것에 반대합니다.

더 간단한 솔루션이 어떻게 작동하는지 알 수 없지만 거기에 뭔가 빠졌을 수도 있습니다.

? 마다 명령 포인터를 저장하고 오류 유형과 연관시킬 수 있습니다.
"모든 오류가 포착되어 다른 오류로 다시 발생합니다." 하지만 Result 에 숨겨진 정보는 어떻게 보존할까요?

하지만 결과에 숨겨진 정보는 어떻게 보존할까요?

결과에 해당 정보를 저장할 필요가 없습니다. 저장해야하는 것은 실패의 원인에 대한 고유 ID이므로 상관 관계를 분석 할 수 있습니다. 그리고 오류 특성은 특성 일 뿐이며 저장 공간이 없기 때문에 대신 결과에 저장할 수 있습니다. 명령어 포인터 vec 자체는 결과에 저장 될 필요가 없으며 TLS로 이동할 수 있습니다.

한 가지 방법은 결과에 대해 failure_id(&self) 메서드를 호출하고 i64 / uuid 또는 실패의 원인을 식별하는 무언가를 반환하는 것입니다.

결과가 스택을 통해 위쪽으로 전달 될 때 컴파일러가 통과하는 스택 프레임을 기록하는 명령어를 주입하기 때문에 필요한 것이 무엇이든 상관없이 언어 지원이 필요합니다. 따라서 결과의 반환은 디버그 빌드에서 다르게 보일 것입니다.

"컴파일러가 스택 프레임을 기록하는 명령어를 삽입합니다."-하지만 ? 는 명시 적입니다. 예외와는 다릅니다. 아니면 통과 한 ? 만 기록하는 것을 좋아하지 않습니까?

어쨌든 수동으로 오류의 압축을 풀고 Err 다시 넣으면 해당 ID가 어떻게 유지됩니까?

"오류 특성은 특성 일 뿐이며 저장 공간이 없기 때문에 대신 결과에 저장할 수 있습니다."
이에 대한 변형이 있습니다. Error 특성을 구현하는 것은 컴파일러에서 특수한 경우에 따라 유형에 정수 필드를 추가하고 유형을 생성하면 ID가 생성 되고 복사 / 삭제가 수행됩니다. refcount를 효과적으로 증가 / 감소시킵니다 (그리고 결국 Result::unwrap 가 사용되지 않는 경우 TLS "in-flight error set"에서이를 지 웁니다).

그러나 그것은 Copy 특성과 충돌합니다. 귀하의 계획도 ? 또는 기타 특정 사용자 작업에 의해 트리거되지 _ 않는 _ Result 특별한 동작을 추가하면 Copy 불변성이 무효화 될 수 있습니다.

편집 :이 시점에서 Rc<ErrorTrace> 를 거기에 포함시킬 수도 있습니다.
EDIT2 : 내가 말하는 것은 catch 에서 관련 오류 추적을 지울 수 있습니다.
EDIT3 : 실제로 드롭시 더 나은 설명을 참조하십시오.

"컴파일러는 자신이 통과하는 스택 프레임을 기록하는 명령을 주입합니다"-하지만? 명시 적입니다. 이것은 예외와 같지 않습니다. 아니면? 통과 했나요?

? 사용하지 않고 넘어갈 수있는 프레임이 너무 많기 때문에 작동하지 않습니다. 모두가 ? 만으로 오류를 처리하는 것은 아닙니다.

어쨌든 수동으로 오류의 압축을 풀고 다시 Err에 넣으면 그 ID가 어떻게 유지됩니까?

이것이 컴파일러 지원이 필요한 이유입니다. 컴파일러는 결과 인 지역 변수를 추적해야하며 재 래핑을 위해 결과 ID를 앞으로 전파하는 것이 가장 좋습니다. 이것이 너무 마법적인 경우 작업의 하위 집합으로 제한 될 수 있습니다.

? 사용하지 않고 넘어갈 수있는 프레임이 너무 많기 때문에 작동하지 않습니다. 모두가 ? 만으로 오류를 처리하는 것은 아닙니다.

좋습니다. Result 반환은 여러 반환 경로가있는 복잡한 함수에서 직접 특수한 경우를 볼 수 있습니다 (일부는 ? 초기 반환).

이것이 너무 마법적인 경우 작업의 하위 집합으로 제한 될 수 있습니다.

또는 완전히 명시 적으로 만들었습니다. 컴파일러가 마술처럼 추적해야하는 비 ? 재 래핑의 예가 있습니까?

@eddyb 오류를 수동으로 처리하는 일반적인 경우는 하위 집합을 처리하려는 IoError입니다.

loop {
  match establish_connection() {
    Ok(conn) => { ... },
    Err(err) => {
      if err.kind() == io::ErrorKind::ConnectionRefused {
        continue;
      } else {
        return Err(err);
      }
    }
  }
}

@mitsuhiko 그러면 ID를 io::Error 안에 보관하면 확실히 작동합니다.

요약하자면, TLS의 Vec<Option<Trace>> "sparse integer map"은 struct ErrorId(usize) 키가 지정되고 3 개의 lang 항목으로 액세스됩니다.

• fn trace_new(Location) -> ErrorId , 비 const 오류 값 생성시
• fn trace_return(ErrorId, Location) , _declared_ 함수에서 -> Result<...> 로 반환하기 직전 (즉, Result 유형과 함께 사용되는 _happens_ 반환시 일반 함수가 아님)
• fn trace_destroy(ErrorId) , 오류 값을 삭제할 때

MIR에서 변환이 수행되면 Location 는 오류 값 생성 또는 Lvalue::Return 쓰기를 트리거하는 명령어의 Span 에서 계산 될 수 있습니다. 명령 포인터 IMO보다 (어쨌든 LLVM에서 쉽게 얻을 수있는 방법은 없습니다. 각 특정 플랫폼에 대해 인라인 asm 를 내 보내야합니다).

@eddyb

바이너리 크기가 커지지 않습니까?

@ arielb1 어쨌든 debuginfo가 바이너리를 부

@eddyb 이 경우 위치는 무엇입니까? IP를 읽는 것이 어려운 것이 무엇인지 확실하지 않습니다. 물론, 각 대상에 대한 사용자 정의 JS가 필요하지만 그다지 어려운 것은 아닙니다.

@mitsuhiko 오버플로 검사 및 기타 컴파일러에서 발생하는 패닉에 사용하는 것과 동일한 정보 일 수 있습니다. core::panicking::panic 참조하십시오.

스택이 풀리는 동안 왜 그렇게 많은 스택 정보를 Error / Result 에 압축합니까? 스택이 아직있는 동안 코드를 실행하지 않는 이유는 무엇입니까? 예를 들어 스택 경로의 변수에 관심이 있다면 어떨까요? Err 가 호출 될 때 사람들이 사용자 지정 코드를 실행할 수 있도록합니다 (예 : 원하는 디버거 호출). 이것은 (재정의 가능한) 매크로이기 때문에 try! 이미 제공하는 것입니다. 가장 쉬운 방법은 올바른 매개 변수로 프로그램을 시작했다면 스택을 인쇄하는 Err 케이스에 당황하는 것입니다.

try 를 사용하면 Err 케이스에서 원하는 모든 작업을 수행 할 수 있으며 매크로 크레이트 전체를 재정의하거나 성능에 중요한 코드를 건드리지 않도록 매우 범위를 지정할 수 있습니다. 예를 들어 오류를 재현하기 어렵고 성능에 중요한 코드를 많이 실행해야합니다.

실제 정보는 파괴 될 것이기 때문에 축적 된 인공 스택에있는 정보의 일부를 보존 할 필요가 없습니다. 모든 매크로 재정의 방법은 다음과 같이 개선 될 수 있습니다.

• ? 는 비슷한 방식으로 재정의 할 수 있습니다. 가장 쉬운 방법은 try! 대한 설탕으로 ? 를 정의하는 것입니다. 특히 상자 테두리에서 다음과 같이 비 원래 오류를 포착하기 위해 필요합니다. 위의 내 의견에 설명되어 있습니다.
• 더 많은 유연성을 허용하기 위해 유형 일치와 같은 더 강력한 매크로 시스템을 가지고 있습니다. 예, 이것을 전통적인 특성 시스템에 넣는 것에 대해 생각할 수 있지만 rust는 특성 구현을 재정의 할 수 없으므로 약간 복잡 할 것입니다.

@ est31 스택은 패닉처럼 _automatically_ "unwound"되지 않습니다. 이것은 초기 수익을위한 구문 적 설탕입니다.
그리고 예, 컴파일러가 중단 점을 지정할 수있는 고정 된 이름을 가진 일부 빈 함수의 호출을 삽입하도록 할 수 있습니다. 이것은 매우 쉽습니다 (예 : call dump(data) -여기서 dump 및 data 는 디버거가 볼 수있는 인수입니다.

@eddyb 빈 함수는 로그에 오류가 나타나는지 확인하기 위해 대규모 배포에 몇 개의 "카나리아"디버그 인스턴스를 유지 한 다음 돌아가서 문제를 해결하는 등의 사용 사례를 허용하지 않을 것이라고 생각합니다. 사후 대응보다 사전 대응하는 것이 더 바람직하지만 모든 것이 예측하기 쉬운 것은 아닙니다.

@hexsel 예, 그래서 Result::unwrap 또는 일부 새로운 ignore 메서드 (또는 오류를 삭제할 때 항상 항상?)가 추적을 stderr로 덤프하는 TLS 기반 메서드를 선호합니다.

@eddyb 명령어 포인터 또는 값에서 파생 된 것을 TLS의 데이터 구조와 같은 스택에 추가하면 기본적으로 실제 스택의 작은 버전을 다시 빌드합니다. 반환은 스택을 한 항목 씩 줄입니다. 따라서 RAM의 다른 위치에 제한된 버전을 빌드하면서 스택의 일부를 _unwind_ 반환하는 동안 그렇게하면. 아마도 "unwind"는 "legal"반환으로 인한 동작에 대한 잘못된 용어 일 수 있지만 모든 코드가 ? 또는 try! 를 수행하고 마지막에 가로 채면 최종 결과가 동일합니다. Rust가 오류 전파를 자동으로 만들지 않는다는 것이 좋습니다. 저는 Java가 throws 키워드 다음에 모든 예외를 나열하도록 요구 한 방식이 정말 마음에 들었습니다. rust는 이에 대한 좋은 개선입니다.

@hexsel 재정의 (이미 try! 대해 이미 존재하므로) 기반 접근 방식을 사용하면 원하는 모든 코드를 실행할 수 있으며 모든 로깅 시스템에 로깅 할 수 있습니다. 여러 try 가 스택 위로 전파 될 때 동일한 오류를 포착 할 때 "중복"에 대한 감지가 필요합니다.

@ est31 try! 재정의는 자신의 코드에서만 작동합니다 (말 그대로 매크로 임포트 섀도 잉). "약한 lang 항목"과 같이 다른 것이되어야합니다.

@ est31 그것은 정말로 정확하지 않습니다 (풀기에 대해), 트레이스와 실제 스택은 반드시 관계가있는 것은 아닙니다. 왜냐하면 Result 를 이동하는 것은 원래의 역 추적에서 올라갈 필요가 없기 때문입니다. 옆으로도.
또한 바이너리가 최적화되면 대부분의 역 추적이 사라지고 디버그 정보가 없으면 Location 가 엄격하게 우수합니다. 모든 소스 정보를 일부 비공개 소스 제품의 개발자가 일치시킬 수있는 임의의 해시로 대체하는 난독 화 플러그인을 실행할 수도 있습니다.

디버거는 유용하지만 (제외로 lldb 의 더 깨끗한 역 추적 출력을 좋아합니다) 만병 통치약이 아니며 이미 패닉에 대한 정보를 출력하여 다음과 같은 단서를 얻을 수 있습니다. 무슨 일이야.

그것에 대해- {Option,Result}::unwrap 에 추가 유형 인수가있는 유형 시스템 수준의 트릭에 대해 몇 가지 생각을했습니다. 기본적으로 함수가 호출 된 위치에 따라 유형이 지정되어 패닉이 발생합니다. 더 유용한 위치 정보.

가치 매개 변수화가 진행됨에 따라 여전히 옵션이 될 수 있지만 확실히 유일한 것은 아니며 Result 트레이스를 완전히 무시하고 싶지는 않지만 대신 _implementable_ 인 모델을 찾으려고합니다.

try! 재정의는 자신의 상자에 포함되어 있기 때문에 전혀 해결책이 아닙니다. 그것은 디버깅 경험으로 받아 들일 수 없습니다. 나는 이미 현재 try! 처리하기 위해 많은 것을 시도했습니다. 특히 많은 상자가 관련되어 있고 스택을 통과하는 도중 오류가 여러 번 변환되는 경우 오류의 원인과 원인을 파악하는 것은 거의 불가능합니다. 이와 같은 반창고가 해결책이라면 대규모 Rust 프로젝트에서 일반적으로 오류 처리를 재검토해야합니다.

@eddyb 그래서 우리가 말 그대로 파일 이름, 함수 이름, 줄 번호 및 열 번호를 해당 벡터에 포함하라는 제안입니까? 특히 해당 정보가 DWARF에서 훨씬 더 처리 가능한 형식으로 이미 포함되어 있기 때문에 매우 낭비적인 것 같습니다. 또한 DWARF를 사용하면 프로덕션에서 동일한 프로세스를 합리적으로 저렴하게 사용할 수 있지만 이러한 종류의 위치 정보는 너무 낭비되어 아무도 릴리스 바이너리를 실행할 수 없습니다.

DWARF 정보보다 훨씬 더 낭비 적일까요? 파일 이름은 중복 제거되고 x64에서는 전체가 포인터 3 개의 크기입니다.

@mitsuhiko 그래서 기본적으로, 당신은 일반적인 방향에 동의하지만 그것의 기술적 세부 사항에는 동의하지 않습니까?

DWARF 정보를 일반 Rust API에 노출하는 것이 얼마나 쉬운가요?

@eddyb 는 DWARF 정보가 릴리스 바이너리에 포함되지 않고 별도의 파일에 포함되어 있기 때문입니다. 그래서 심볼 서버에 디버그 파일을 갖고 사용자에게 스트립 된 바이너리를 보낼 수 있습니다.

@mitsuhiko 아, 그것은 내가 생각했던 것과 완전히 다른 접근 방식입니다. Rust는 현재 그 atm, AFAIK를 지원하지 않지만, 그래야한다는 데 동의합니다.

릴리스 바이너리 디버깅을 위해 빌드 시스템에서 생성 한 임의의 식별자에 비해 명령 포인터가 실제로 유용하다고 생각하십니까?

내 경험에 따르면 모든 인라인 디버거는 명시 적 자체 / 상호 재귀 및 매우 큰 함수를 제외하고 스택 추적의 대부분을 복구하는 데 어려움을 겪었습니다.

예, try! 은 (는) 상자 안에 들어 있습니다. 함수 포인터 또는 유사한 라이브러리 코드를 전달하고 함수에 오류가있는 경우 try 접근 방식이 계속 작동합니다. 사용하는 크레이트에 내부 오류 또는 버그가있는 경우 반환 된 Err 의 정보가 도움이되지 않는 경우 이미 디버그하기 위해 소스 코드가 필요할 수 있습니다. 스택 추적은 코드에 대한 액세스 권한이있는 경우에만 유용하므로 폐쇄 된 소스 라이브러리 (코드를 수정할 수없는 경우)는 어떤 식 으로든 지원을 받아야합니다.

두 가지 접근 방식을 모두 활성화하고 개발자가 가장 적합한 방식을 결정하도록하는 것은 어떻습니까? 나는 TLS 기반 접근 방식이 이점이 없다는 것을 부정하지 않습니다.

try 모델은 매우 쉽게 구현할 수 있습니다. ? 에서 try 간단히 제거합니다. catch 이 들어 오면 추가 언어 확장 만 필요합니다 (하드 코딩 된 동작 안에 해당 동작을 추가했을 것입니다) 어쨌든 ? )

@eddyb "명령 포인터가 릴리스 바이너리 디버깅을 위해 빌드 시스템에서 생성 된 임의의 식별자와 비교할 때 실제로 유용하다고 생각하십니까?"

이것이 일반적으로 네이티브 바이너리 디버깅이 작동하는 방식입니다. 우리 (Sentry)는 현재 거의 전적으로 iOS 지원을 위해 사용하고 있습니다. 크래시 덤프를 얻고 llvm-symbolizer를 사용하여 주소를 실제 기호로 확인합니다.

@mitsuhiko 이미 libbacktrace 포함했기 때문에 소스 위치에 대한 코드 포인터를 해석하는 데 사용할 수 있으므로 전적으로 반대하지 않습니다.

@eddyb 예. 패닉 코드를 보았습니다. 그것이 실제로 Rust 코드가 사용할 수있는 API라면 좋을 것입니다. 더 많은 곳에서 이것이 유용하다는 것을 알 수 있습니다.

그것에 대해-나는 {Option, Result} :: unwrap에 추가 유형 인수가있는 유형 시스템 수준의 트릭에 대해 몇 가지 생각을했습니다. 더 유용한 위치 정보가 있습니다.

말하자면...

@glaebhoerl Hah, 아마도 그것은 실제로 추구 할 가치가 있습니까? 적어도 불안정한 실험만큼.

@eddyb 모르겠어요. 아마도 먼저 그것에 관련된 GHCer들과 논의 할 가치가있을 것입니다. 나는 단지 이것에 대해 들었고 방금 링크를 봤습니다. 그리고 Rust는 GHC와 같은 방식으로 실제 암시 적 매개 변수를 가지고 있지 않습니다. 기본 유형 매개 변수가 대신 작동 할 수 있는지 여부는 흥미로운 질문입니다 (아마도 나보다 더 많이 생각한 질문 일 것입니다).

그냥 생각하세요 : rustc 를 Err 구성하는 특수한 경우로 전환하는 스위치를 사용하여 반환하기 전에 페이로드와 함께 fn(TypeId, *mut ()) 함수를 호출하는 것이 유용 할 것입니다. . 페이로드를 기반으로 오류를 필터링하거나, 관심있는 오류가 발견되면 디버거에 트랩하거나, 특정 종류의 오류에 대한 역 추적을 캡처하는 것과 같은 기본적인 작업으로 시작하기에 충분합니다.

PR 33389 는 Carrier 특성에 대한 실험적 지원을 추가합니다. 원래 RFC의 일부가 아니기 때문에 FCP로 이동하기 전에 특히 가까운 검사 및 논의 기간을 거쳐야합니다 (나머지 ? 연산자에 대해서는 FCP와 분리되어야 함). 자세한 내용은이 토론 스레드 를 참조하십시오.

? 를 Option 로 연장하는 것에 반대합니다.

RFC의 표현은 ? 연산자가 오류 / "예외"전파에 관한 것이라는 사실에 대해 매우 명확합니다.
Option 를 사용하여 오류를보고하는 것은 잘못된 도구입니다. None 반환은 성공적인 프로그램의 정상적인 워크 플로의 일부이며 Err 반환

오류 처리의 일부 영역 (예 : 스택 추적 추가)을 개선하려는 경우 ? 에 Option ? 를 구현하면 ? 를 변경에서 제외해야합니다. .

@tomaka 토론 스레드 에서 토론을 계속할 수 있습니까? ( 이미 귀하의 이의를 요약했습니다. ) 저는 개인적으로 GH에 대한 긴 논의가 상당히 다루기 힘들다는 것을 알고 있으며,이 특정 논의를 다른 미래의 포인트 또는 발생할 수있는 질문과 분리 할 수있는 것도 좋을 것입니다.

@eddyb 여기 I 기능 GHC 암시 적 호출 스택의 출시 버전의 문서 앞에서 언급 .

잠시 동안 여기에 업데이트가 없습니다. 이 문제를 해결하기 위해 노력하는 사람이 있습니까? OP의 나머지 작업이 여전히 정확합니까? 여기에 전자 도움이 필요한 것이 있습니까?

나는 지난 주말에 Rust 용 Sentry 클라이언트를 작성하는 것이 가능하다면 놀았습니다. 대부분의 오류 처리는 실제로 패닉 대신 결과를 기반으로하기 때문에 이것의 유용성은 내가 이것을 완전히 포기하기로 결정한 지점으로 심각하게 제한된다는 것을 알았습니다.

오류보고 시스템을 여기에 통합하기 위해 crates.io 코드베이스를 예로 들어 보았습니다. 결과가 전달되고 다른 스택 트레이스에서 변환 될 때 어떻게 든 명령 포인터를 기록 할 수 없다면 적절한 오류보고를 얻을 수 없다고 생각하기 때문에이 RFC로 다시 돌아 왔습니다. 나는 이미 이것이 내가 _ 생각하는 _ 오류가 발생한 곳에 패닉을 추가하는 데 의지하는 지역의 복잡한 논리 오류를 디버깅하는 것만으로도 엄청난 고통임을 이미 알고 있습니다.

불행히도 결과가 작동하는 방식을 크게 변경하지 않고 IP를 기록 할 수있는 방법을 현재 알 수 없습니다. 다른 사람이 전에이 아이디어를 가지고 놀았 던 적이 있습니까?

우리는 @ rust-lang / lang 회의에서 이에 대해 논의했습니다. 올라온 몇 가지 :

첫째, ? 가 가능한 한 빨리 안정화되는 것을 보는 데 확실한 관심이 있습니다. 그러나 우리 대부분은 Result 뿐만 아니라 Option 에서 ? 작동하는 것을보고 싶어한다고 생각합니다 (하지만 bool 라고 생각합니다. 또한 제안되었습니다). 안정화에 대한 한 가지 우려 사항은 Result 이외의 유형을 사용할 수있는 어떤 종류의 특성도 제공하지 않고 안정화하면 나중에 추가 할 수있는 하위 호환성이 없다는 것입니다.

예를 들어, 저는 규칙적으로 다음과 같은 코드를 작성합니다.

let v: Vec<_> = try!(foo.iter().map(|x| x.to_result()).collect());

try! 을 사용하여 collect 이 Result<Vec<_>, _> 를 반환 할 것으로 예상하는 유형 추론을 알립니다. ? 를 사용한다면이 추론은 _ 미래에 실패 할 수도 있습니다.

그러나 이전 논의에서 우리는 또한 모든 종류의 "운반자"특성에 대한 세부 사항을 논의하기 위해 수정 RFC가 필요하다고 결정했습니다. 분명히이 RFC는 최대한 빨리 작성해야하지만 해당 토론에서 ? 진행을 차단하지 않는 것이 좋습니다.

한 가지 생각은 @nrc 의 구현을 가져 Result 및 일부 개인 더미 유형에 대해서만 구현하면 ? 만 만들면서 추론을 억제해야한다는 것입니다. Result .

마지막 요점 : 우리 대부분은 Option 값에 ? 를 사용하는 경우 함수의 반환 유형도 Option 여야합니다 (예 : Result<T,()> ). 이것은 추론 제한에 도움이 될 것입니다. 많은 경우에 선언 된 반환 유형에서 어떤 유형이 필요한지 추론 할 수 있기 때문입니다.

상호 변환을 원하지 않는 이유는 x 에 정수 유형이 있더라도 C가 if x 허용하는 것과 유사한 느슨한 논리로 이어질 가능성이 있기 때문입니다. 즉, Option<T> 가 값을 나타내며 None 는 해당 값의 도메인의 일부이고 Result<> 는 (일반적으로) 함수의 실패를 나타냅니다. 성공하려면 None 함수가 오류가 의심 스러워야한다는 것을 의미한다고 가정하면 (그리고 임의의 규칙처럼). 그러나 그 논의는 RFC를 기다릴 수 있다고 생각합니다.

상호 변환을 원하지 않는 이유는 x 에 정수 유형이 있더라도 C가 if x 허용하는 것과 유사한 느슨한 논리로 이어질 가능성이 있기 때문입니다. 즉, Option<T> 가 값을 나타내며 None 는 해당 값의 도메인의 일부이고 Result<> 는 (일반적으로) 함수의 실패를 나타냅니다. 성공하려면 None 함수가 오류가 의심 스러워야한다는 것을 의미한다고 가정하면 (그리고 임의의 규칙처럼). 그러나 그 논의는 RFC를 기다릴 수 있다고 생각합니다.

나는 이것에 진심으로 동의합니다.

게이트 안정화에 동의 한 또 다른 질문은 From 특성의 impl s가 따라야 할 계약 (또는 Err -upcasting ).

뿡 빵뀨

게이트 안정화에 동의 한 또 다른 질문은 From 특성의 impls가 준수해야하는 계약 (또는 Err-upcasting에 사용하는 특성)을 정하는 것이 었습니다.

과연. 내 기억을 되 살리고 금지되어야한다고 생각하는 몇 가지 예부터 시작할 수 있습니까? 아니면 당신이 염두에두고있는 법칙일까요? 나는 이와 같은 "법률"을 경계하고 있음을 인정해야합니다. 우선, 그들은 실제로 무시되는 경향이 있습니다. 사람들은 의도 된 한계를 넘어서더라도 목적에 맞을 때 실제 행동을 이용합니다. 그래서 그것은 또 다른 질문으로 이어집니다. 만약 우리에게 법이 있다면, 우리는 그것을 어떤 용도로 사용할 것인가? 최적화? (하지만 나에게는 없을 것 같습니다.)

그런데 catch 표현식의 상태는 어떻습니까? 구현 되었습니까?

슬프게도 아니오 :(

2016 년 7 월 26 일 화요일 06:41:44 AM -0700에 Alexander Bulaev는 다음과 같이 썼습니다.

그런데 catch 표현식의 상태는 어떻습니까? 구현 되었습니까?

---

스레드를 작성했기 때문에 수신 한 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/31436#issuecomment -235270663

구현을 계획해야할까요? 받아 들여졌지만 구현되지 않은 RFC보다 더 우울한 것은 없습니다 ...

참조 # 35056

참고로, https://github.com/rust-lang/rfcs/pull/1450 (열거 형 변형 유형)은 Carrier 구현하는 몇 가지 흥미로운 방법을 열 것입니다. 예를 들면 다음과 같습니다.

trait Carrier {
    type Success: CarrierSuccess;
    type Error: CarrierError;
}

trait CarrierSuccess {
    type Value;
    fn into_value(self) -> Self::Value;
}

// (could really use some HKT...)
trait CarrierError<Equivalent: CarrierError> {
    fn convert_error(self) -> Equivalent;
}

impl<T, E> Carrier for Result<T, E>
{
    type Success = Result::Ok<T, E>;
    type Error = Result::Err<T, E>;
}

impl<T, E> CarrierSuccess for Result::Ok<T, E> {
    type Value = T;
    fn into_value(self) -> Self::Value {
        self.0
    }
}

impl<T, E1, E2> CarrierError<Result::Err<T, E2>> for Result::Err<T, E1>
    where E2: From<E1>,
{
    fn convert_error(self) -> Result::Err<T, E2> {
        Err(self.into())
    }
}

impl<T> Carrier for Option<T>
{
    type Success = Option::Some<T>;
    type Error = None;
}

impl<T> CarrierSuccess for Option::Some<T> {
    type Value = T;
    fn into_value(self) -> Self::Value {
        self.0
    }
}

impl<T> CarrierError<Option::None> for Option::None {
    fn convert_error(self) -> Option::None {
        self
    }
}

fn main() {
    let value = match might_be_err() {
        ok @ Carrier::Success => ok.into_value(),
        err @ Carrier::Error => return err.convert_error(),
    }
}

https://github.com/rust-lang/rust/pull/35056#issuecomment -240129923에서 몇 가지 생각을 교차 게시하고 싶었습니다. 그 PR은 더미 유형의 Carrier 특성을 소개합니다. 의도는 보호를위한 것이 었습니다. 특히 유형 추론과의 상호 작용을 안정화하지 않고도 ? 를 안정화하고자했습니다. 이 특성과 더미 유형의 조합은 안전하게 보수적 일 것 같았습니다.

아이디어는 우리가 Carrier 논의하는 RFC를 작성하고 일치하도록 디자인을 수정하여 전체 모양에 만족할 때만 안정화 (또는 Carrier 제거 가능) 우리가 좋아하는 디자인에 도달 할 수없는 경우 모두

이제 조금 더 추측 적으로 말하면, Carrier 특성을 채택하면 캐리어 간의 상호 변환을 허용하지 않을 것입니다 (이 특성은 기본적으로 Result 로 /에서 변환하는 방법입니다). ? 를 Option 에 적용하면 fn이 Option 반환해도 괜찮습니다. ? 를 Result<T,E> 에 적용하면 fn이 Result<U,F> 반환하면 괜찮습니다. 여기서 E: Into<F> ; 하지만 ? 을 Option 하고 fn이 Result<..> 반환하면 괜찮지 않습니다.

즉, 이러한 종류의 규칙은 오늘날의 유형 시스템에서 표현하기 어렵습니다. 가장 분명한 시작점은 HKT와 같은 것입니다 (물론 실제로는 없지만 지금은 무시하겠습니다). 그러나 그것은 분명히 완벽하지 않습니다. 우리가 그것을 사용한다면, 하나는 가정 것이 그 Self 매개 변수 Carrier 이 종류의 type -> type -> type , 이후 Result 구현할 수 Carrier . 그러면 Self<T,E> -> Self<U,F> 같은 것을 표현할 수 있습니다. 그러나 type -> type 종류가있는 Option 반드시 적용되는 것은 _ 아닙니다 _ (이 모든 것은 우리가 채택한 HKT 시스템의 종류에 따라 정확히 달라 지겠지만 저는 우리가 "일반형 람다"로 끝까지 갈 것입니다). 더 극단적 인 것은 bool 와 같은 유형일 수 있습니다 (부울에 대해 Carrier 를 구현하고 싶지는 않지만 일부 사람들은 newtype에 대해 Carrier 를 구현하고 싶을 것입니다. 'd bool).

제가 고려한 것은 ? 대한 입력 규칙 자체가 특별 할 수 있다는 것입니다. 예를 들어 ? Foo<..> 는 _some_의 명목 유형 Carrier 특성과 일치하지만 fn을 둘러싼 반환 유형도 Foo<..> 합니다. 따라서 기본적으로 새로운 유형 매개 변수로 Foo 를 인스턴스화합니다. 이 아이디어의 단점은 ? 이 적용되는 유형이나 둘러싸는 fn의 유형을 알 수없는 경우 새로운 종류의 특성 의무를 추가하지 않고는이 제약을 적용 할 수 없다는 것입니다. 또한 다소 임시적입니다. :)하지만 작동합니다.

또 다른 생각은 Carrier 특성을 재고 할 수 있다는 것입니다. 아이디어는 Expr: Carrier<Return> 를 갖는 것입니다. 여기서 Expr 는 ? 유형이 적용되고 Return 는 환경 유형입니다. 예를 들어 다음과 같이 보일 수 있습니다.

trait Carrier<Target> {
    type Ok;
    fn is_ok(&self) -> bool; // if true, represents the "ok-like" variant
    fn unwrap_into_ok(self) -> Self::Ok; // may panic if not ok
    fn unwrap_into_error(self) -> Target; // may panic if not error
}

그런 다음 expr? 탈당 :

let val = expr;
if Carrier::is_ok(&val) {
    val.unwrap_into_ok()
} else {
    return val.unwrap_into_error();
}

여기서 중요한 차이점은 Target 는 _error_ 유형이 아니라 새로운 Result 유형이라는 것입니다. 예를 들어 다음과 같은 impl을 추가 할 수 있습니다.

impl<T,U,E,F> Carrier<Result<U,F>> for Result<T,E>
    where E: Into<F>
{
    type Ok = T;
    fn is_ok(&self) -> bool { self.is_ok() }
    fn unwrap_into_ok(self) -> Self::Ok { self.unwrap() }
    fn unwrap_into_error(self) -> { Err(F::from(self.unwrap_err())) }
}

그리고 다음을 추가 할 수 있습니다.

impl<T> Carrier<Option<T>> for Option<T> {
    type Ok = T;
    fn is_ok(&self) -> bool { self.is_some() }
    fn unwrap_into_ok(self) -> Self::Ok { self.unwrap() }
    fn unwrap_into_error(self) -> { debug_assert!(self.is_none()); None }
}

마지막으로 다음과 같이 bool을 구현할 수 있습니다.

struct MyBool(bool);
impl<T> Carrier<MyBool> for MyBool {
    type Ok = ();
    fn is_ok(&self) -> bool { self.0 }
    fn unwrap_into_ok(self) -> Self::Ok { debug_assert!(self.0); () }
    fn unwrap_into_error(self) -> { debug_assert!(!self.0); self }
}

이제이 버전은 더 유연합니다. 예를 들어 다음과 같이 Result 을 추가하여 impl Option 값 간의 상호 변환을 Result 로 변환 할 수 _ 가능합니다 _.

impl<T> Carrier<Result<T,()>> for Option<T> { ... }

그러나 물론 우리는 그럴 필요가 없습니다 (그리고 그렇게하지 않을 것입니다).

뿡뿡

참고로 rust-lang / rfcs # 1450 (열거 형 변형의 유형)은 Carrier를 구현하는 몇 가지 흥미로운 방법을 열 것입니다.

방금 작성한 아이디어를 작성하면서 열거 형 변형에 대한 유형을 갖는 것과 그것이 어떤 영향을 미칠지에 대해 생각하고있었습니다.

? 를 사용하는 코드를 작성하는 한 가지 사실은 "throw"키워드를 사용하지 않는 것이 약간 성가신 것입니다. 특히 Err(foo)? 를 작성하면 컴파일러가 t _know_ 이것이 반환 될 것이므로 return Err(foo) 를 작성해야합니다. 괜찮지 만 직접 작성하지 않고는 into() 전환을 얻을 수 없습니다.

이것은 다음과 같은 경우에 나타납니다.

let value = if something_or_other() { foo } else { return Err(bar) };

아, 한 가지 더 추가해야합니다. impls가 유형 추론에 영향을 미칠 수 있도록 허용한다는 사실은 _should_ fn이 Result<..> 반환하는 컨텍스트에서 foo.iter().map().collect()? 의미합니다. fn 반환 유형은 Result 이며 하나의 impl 만 잠재적으로 적용됩니다 (적어도 로컬에서).

아, 그리고 내 Carrier 특성의 약간 더 나은 버전은 아마도 다음과 같을 것입니다.

trait Carrier<Target> {
    type Ok;
    fn into_carrier(self) -> Result<Self::Ok, Target>;
}

다음과 같이 구현할 수 있습니다.

impl<T,U,E,F> Carrier<Result<U,F>> for Result<T,E>
    where E: Into<F>
{
    type Ok = T;
    fn into_carrier(self) -> Result<T, Result<U,F>> {
        match self { Ok(v) => Ok(v), Err(e) => Err(e.into()) }
    }
}

그리고 expr? 는 다음과 같은 코드를 생성합니다.

match Carrier::into_carrier(expr) {
    Ok(v) => v,
    Err(e) => return e,
}

물론 이것의 단점 (또는 장점 ...)은 Into 변환이 impls로 푸시된다는 것입니다. 즉, 사람들이 의미가있을 때 사용하지 않을 수도 있습니다. 그러나 원하지 않는 경우 (특정 유형에 대해) 비활성화 할 수도 있습니다.

@nikomatsakis IMO, 특성은 IntoCarrier 이어야하며 IntoCarrier::into_carrier 는 이와 같은 결과를 재사용하는 대신 Carrier (새 열거 형)을 반환해야합니다. 그건:

enum Carrier<C, R> {
    Continue(C),
    Return(R),
}
trait IntoCarrier<Return> {
    type Continue;
    fn into_carrier(self) -> Carrier<Self::Continue, Return>;
}

@ Stebalien 확실히 괜찮아 보입니다.

lang 팀 회의에서 토론 (및 ? 운영자 만 가능한 FCP)을 위해 지명합니다. 나는 우리가 FCP에 앞으로 며칠 안에 일종의 일시적인 Carrier 특성을 착륙시켜야한다고 생각합니다.

Carrier 특성에 대해 논의하기 위해 rust-lang / rfcs # 1718을 열었습니다.

들으십시오, 들으십시오! ? 연산자는 이제 최종 댓글 기간을 입력하고 있습니다. 이 토론은 8 월 18 일에 시작된 대략이 릴리스주기 동안 지속됩니다. 경향은 ? 연산자를 안정화 하는 것입니다.

캐리어 특성 과 관련하여, 유형 추론과의 원치 않는 상호 작용을 방지하여 어느 쪽이든 자유롭게 결정할 수 있도록하는 임시 버전이 # 35777에 도착했습니다.

@ rust-lang / lang 회원님, 동의를 표시하려면 이름을 확인하세요. 우려 사항이나 이의가있는 의견을 남겨주세요. 기타 의견을 남겨주세요. 감사!

• [x] @nikomatsakis
• [x] @nrc
• [x] @aturon
• [x] @eddyb
• [] @pnkfelix (휴가 중)

tokio 기반 라이브러리가 and_then 많이 사용하게 될지 궁금합니다. 이는 foo().?bar() 를 foo().and_then(move |v| v.bar()) 축약 형으로 사용하여 결과와 선물이 동일한 표기법을 사용할 수 있도록하는 하나의 인수입니다.

명확하게 말하면,이 FCP는 question_mark 기능에 관한 것이지 catch가 아닙니다. 맞습니까? 이 호의 제목은 이번 호에서 두 기능을 모두 추적한다는 것을 의미합니다.

@seanmonstar 후자는 구현되지 않았으므로 예. 아마도 FCP가 수락 결과를 가져 오면 catch 추적하도록 변경 될 것입니다.

명확하게 말하면이 FCP는 question_mark 기능에 관한 것이지 catch가 아닙니다. 맞습니까? 이 호의 제목은 이번 호에서 두 기능을 모두 추적한다는 것을 의미합니다.

예, question_mark 기능

https://github.com/rust-lang/rfcs/issues/1718#issuecomment -241764523 후속 조치. 나는 현재의 행동을 생각했다 ? "바인드 현재 계속"으로 일반화하지만, 수 map_err(From::from) 부분 ? / : 그것은 약간 더 방금 바인드보다 수에게. 결과에 대해 From 인스턴스를 모두 추가하면 의미 체계가 v? => from(v.bind(current-continuation)) 수 있다고 가정합니다.

이 내부 스레드에서 ? 의 상대적인 장점에 대해 많은 논의가있었습니다.

https://internals.rust-lang.org/t/the-operator-will-be-harmful-to-rust/3882/

지금은 심층 요약을 할 시간이 없습니다. 내 기억은 댓글이 ? 가 오류에주의를 기울일만큼 충분히 보이는지에 대한 질문에 초점을 맞추고 있다는 것입니다.하지만 토론의 다른 측면을 간과하고 있습니다. 다른 사람이 요약 할 시간이 있다면 좋을 것입니다!

나는 이전에 주석을 달지 않았고 이것은 너무 늦었을 수도 있지만 ? 연산자가 숨겨진 return 문으로 사용되면 혼란 스럽습니다. @ hauleth 가 @를 링크 한 토론에서 지적했듯이 nikomatsakis.

try! 하면 매크로가이를 수행 할 수 있기 때문에 어딘가에 반환이있을 수 있음이 분명했습니다. ? 를 숨겨진 return 로 사용하면 함수에서 값을 반환하는 세 가지 방법이 있습니다.

• 암시 적 반환
• 명시 적 반품
• ?

@CryZe가 말했듯이 나는 이것을 좋아합니다.

이렇게하면 모든 사람에게 친숙하고 오류를 끝까지 전달하여 처리 할 수 ​​있으며 암시 적 반환이 없습니다. 따라서 대략 다음과 같이 보일 수 있습니다.

let a = try! (x? .y? .z);

이는 코드를 더 간결하게 만들고 반환을 숨기지 않는 데 도움이됩니다. 그리고 coffeescript 와 같은 다른 언어에서도 익숙합니다.

? 함수 수준 대신 식 수준에서 해결하면 선물에 어떤 영향을 미칠까요? 다른 모든 사용 사례에서는 괜찮아 보입니다.

@CryZe가 말했듯이 나는 이것을 좋아합니다.

이렇게하면 모든 사람에게 친숙하고 오류를 끝까지 전달하여 처리 할 수 ​​있으며 암시 적 반환이 없습니다. 따라서 대략 다음과 같이 보일 수 있습니다.

let a = try! (x? .y? .z);

나는 이것을 가정했다. 완벽한 해결책이 될 것 같아요.

try!를 사용하면 매크로가이를 수행 할 수 있기 때문에 어딘가에 반환이있을 수 있다는 것이 분명했습니다.

Rust에서 매크로가 작동하는 방식에 익숙하기 때문에 분명합니다. ? 가 안정적이고 널리 퍼져 있고 Rust에 대한 모든 소개에서 설명되면 똑같을 것입니다.

안녕하세요.

함수에서 값을 반환하는 세 가지 방법이 있습니다.

• 암시 적 반환

Rust에는 "암시 적 반환"이 없으며 값으로 평가되는 표현식이 있습니다. 이것은 중요한 차이점입니다.

if foo {
    5
}

7

Rust가 "암시 적 리턴"을 가졌다면이 코드는 컴파일됩니다. 하지만 그렇지 않습니다. return 5 합니다.

어느 것이 한 번 똑같 을까요? 안정적이고 널리 퍼져 있으며 Rust에 대한 모든 소개에서 설명됩니다.

예를 들어 https://github.com/rust-lang/book/pull/134

try!를 사용하면 매크로가이를 수행 할 수 있기 때문에 어딘가에 반환이있을 수 있다는 것이 분명했습니다.
Rust에서 매크로가 작동하는 방식에 익숙하기 때문에 분명합니다. 어느 것이 한 번 똑같 을까요? 안정적이고 널리 퍼져 있으며 Rust에 대한 모든 소개에서 설명됩니다.

내가 알고있는 어떤 언어로든 "매크로"는 "용이 여기있다"라는 뜻이며 무슨 일이든 일어날 수 있다는 뜻입니다. 그래서 "In Rust"부분없이 "매크로가 작동하는 방식에 익숙하기 때문에"로 다시 표현하겠습니다.

@hauleth

let a = try! (x? .y? .z);

나는 이것을 가정했다. 완벽한 해결책이 될 것 같아요.

나는 매우 동의하지 않습니다. try! 에서만 작동하고 외부에서는 작동하지 않는 마술 기호를 얻게됩니다.

@hauleth

let a = try! (x? .y? .z);
나는 이것을 가정했다. 완벽한 해결책이 될 것 같아요.
나는 매우 동의하지 않습니다. 시도에서만 작동하는 마법의 상징을 얻을 것입니다! 외부가 아닙니다.

? 는 try! 에서만 작동해야한다고 말하지 않았습니다. 내가 말한 것은 ? 가 데이터를 스트림 아래로 밀어 내고 발생하자마자 오류를 반환하는 파이프 연산자처럼 작동해야한다는 것입니다. try! 는 필요하지 않지만 현재 사용되는 것과 동일한 컨텍스트에서 사용할 수 있습니다.

@steveklabnik 저는 Rust를 암시 적 반환을 갖는 언어로 생각합니다. 귀하의 예에서 5 는 암시 적으로 반환되지 않았지만 다음을 수행합니다.

fn test() -> i32 {
    5
}

여기에서 5 가 암시 적으로 반환되지 않습니까? return 5; 와는 반대로 귀하의 예에서 필요합니다. 이렇게하면 값을 반환하는 두 가지 방법이 있습니다. Rust에 대해 다소 혼란 스럽습니다. 세 번째를 추가하면 IMO에 도움이되지 않습니다.

그렇지 않습니다. 표현식, 특히 함수 본문의 결과입니다. "암시 적 반환"은 묵시적으로 어디에서나 반환 할 수 있음을 의미하지만 사실이 아닙니다. 다른 표현식 기반 언어에서는 위의 코드 샘플처럼 "암시 적 반환"이라고 부르지 않습니다.

@steveklabnik 좋습니다 . 시간을내어 설명해 주셔서 감사합니다 : +1 :

전부다 괜찮아! 나는 당신이 어디에서 왔는지 완전히 볼 수 있습니다. 사람들이 종종 잘못된 방식으로 사용하는 두 가지 다른 것입니다. 나는 사람들이 "암시 적 반환"이란 ; 를 소스의 어디에서나 반환 할 수 있다는 것을 의미한다고 가정하는 것을 보았습니다.

@hauleth 는? 연산자는이 경우 and_then에 대한 구문 설탕 일 것입니다. 이렇게하면 더 많은 경우에 사용할 수 있으며 반품을 놓치기 어려울 필요가 없습니다. 이것은 또한 다른 모든 언어가 무엇입니까? 운영자. 러스트? 현재 구현에서 연산자는 다른 모든 언어가 수행하는 것과 정확히 반대입니다. 또한 and_then은 기능적 접근 방식이며 명확한 제어 흐름이 있기 때문에 어쨌든 권장됩니다. 그래서 그냥 만들어? and_then에 대한 구문 설탕을 사용한 다음 현재 시도를 유지하십시오! 명시 적으로 "언 래핑 및 반환"의 경우 반환을 더 잘 보이게하고? 연산자가 더 유연합니다 (패턴 일치와 같은 비 반환 사례에서 사용할 수 있음).

바로 그거죠.

Łukasz Niemier
[email protected]

Wiadomość napisana przez Christopher Serr [email protected] w dniu 02.09.2016, o godz. 21:05 :

@hauleth https://github.com/hauleth ? 연산자는이 경우 and_then에 대한 구문 설탕 일 것입니다. 이렇게하면 더 많은 경우에 사용할 수 있으며 반품을 놓치기 어려울 필요가 없습니다. 이것은 또한 다른 모든 언어가 무엇입니까? 운영자. 러스트? 현재 구현에서 연산자는 다른 모든 언어가 수행하는 것과 정확히 반대입니다. 또한 and_then은 기능적 접근 방식이며 명확한 제어 흐름이 있기 때문에 어쨌든 권장됩니다. 그래서 그냥 만들어? and_then에 대한 구문 설탕을 사용한 다음 현재 시도를 유지하십시오! 명시 적으로 "언 래핑 및 반환"의 경우 반환을 더 잘 보이게하고? 연산자가 더 유연합니다 (패턴 일치와 같은 비 반환 사례에서 사용할 수 있음).

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/rust-lang/rust/issues/31436#issuecomment -244461722에서 보거나 https://github.com/notifications/unsubscribe-auth/ 스레드를 음소거합니다.

그리고 Rust 리포지토리에 대한 Pull Request 작업을 할 때 실제로? 연산자와 사실 그것은 나에게 정말 가독성을 해친다. (정신적으로, 뇌에서 걸러지는 소음 일 뿐이 기 때문에) 엄청나게 숨겨져 있었고 저는 그것을 많이 간과했습니다. 그리고 나는 그것이 매우 무섭다는 것을 안다.

우리가 "암시 복귀"를 호출 @steveklabnik 때문에 우리가 하지 유일한 것들 .

@hauleth 허, 루비를 사용하는 동안 나는 그것을 암시 적 반환이라고 부르는 사람을 들어 본 적이 없습니다. 나는 그것이 그것에 대해 생각하는 잘못된 방법이라고 여전히 주장합니다.

나는 몇 가지 프로젝트에서 ? 를 사용했고 try! 보다 선호했는데, 대부분은 접미사 위치에 있기 때문입니다. 일반적으로, "진짜"녹 코드는 꽤 많이 들어갑니다 Result 에서 '모나드' main 가끔 리프 노드에서 제외를 결코 떠나지 않는다; 이러한 코드는 항상 오류를 전파 할 것으로 예상됩니다. 대부분의 경우 어떤 표현식이 오류를 생성하는지는 중요하지 않습니다. 모두 스택으로 다시 보내지고 있으며 코드의 주요 논리를 읽을 때이를보고 싶지 않습니다.

? 대한 나의 주요 관심사는 메서드 매크로가 존재한다면 동일한 이점 (접미사 위치)을 얻을 수 있다는 것입니다. 나는 아마도 현재의 공식을 안정화함으로써 우리가 오류 처리에서 미래의 표현성을 제한하고 있다는 다른 우려가 있습니다. 현재 Result 변환은 Rust에서 오류 처리를 원하는만큼 인체 공학적으로 만들기에 충분하지 않습니다. 우리는 이미 수정하기 어려운 Rust 오류 처리로 여러 디자인 실수를 저질렀 고, 이것은 우리를 더 깊이 파고들 수 있습니다. 구체적인 증거는 없지만

나는 전에 이것을 여러 번 썼지 만 ? 와 캐리어 특성의 가능성을 절대적으로 좋아합니다. 나는 하나의 프로젝트를 ? 완전히 사용하도록 전환했고 try! 과는 너무 복잡한 많은 일을 가능하게했습니다 (특히 체인과 관련하여). 나는 또한 재미로 ? 어떤 일을 할 수 있는지보기 위해 다른 프로젝트를 살펴 봤고 전반적으로 나는 그것에 어떤 문제도 발생하지 않았습니다.

따라서 저는 더 나은 이름의 Carrier 특성을 기반으로 ? 안정화에 큰 +1을 제공합니다.이 특성은 이상적으로는 다른 토론에서 언급 한 다른 일부 사례도 포함합니다.

나의 주요 관심사는? 메소드 매크로가 존재한다면 동일한 이점 (접미사 위치)을 얻을 수 있다는 것입니다.

RFC가 필요할까요? 대부분의 사람들은?의 기능을 좋아하는 것 같지만? 그 자체.

RFC가 필요할까요? 대부분의 사람들은?의 기능을 좋아하는 것 같지만? 그 자체.

이에 대해 많은 논의가있는 RFC 가 있습니다. 또한 나는 당신이 그 "대부분의 사람들"을 어디서 얻는 지 모릅니다. 이 문제에 참여한 사람이라면 물론 안정화가 _ 이미 _ 팀의 기본 조치이기 때문에 더 많은 사람들이 반대하는 것을 보게 될 것입니다.
? 는 RFC가 병합되기 전에 크게 논의되었으며, 지지자로서 안정화에 대해 논의 할 때 동일한 작업을 수행해야하는 것은 다소 피곤합니다.

어쨌든 여기에 @mitsuhiko 님 의 감정에 대한 +1을

이에 대해 많은 논의가있는 RFC가 있습니다. 또한 나는 당신이 그 "대부분의 사람들"을 어디서 얻는 지 모릅니다. 이 문제에 참여한 사람들의 경우 안정화가 이미 팀의 기본 조치이기 때문에 더 많은 사람들이 반대하는 것을 볼 수 있습니다.

죄송합니다. 제 댓글이 너무 짧습니다. 예를 들어 func1().try!().func2().try!() 와 같은 일종의 "메서드 매크로"에 대한 RFC를 만드는 것을 언급했습니다 (내가 아는 한 현재 불가능합니다).

개인적으로 나는? 연산자이지만 @brson 과 동일한 우려를 공유 @nikomatsakis가 연결 한 내부 스레드를 포함하여 동일한 인수가 반복

기능을 완전히 구현하지 않고 안정화하는 것은 시기상조 인 것 같습니다.이 경우 catch {..} 표현식입니다.

이전에이 기능에 대한 우려를 표명했지만 여전히 나쁜 생각이라고 생각합니다. 후위 조건부 반환 연산자를 사용하는 것은 다른 프로그래밍 언어와는 다르며 Rust가 이미 늘어난 복잡성 예산을 넘어서고 있다고 생각합니다.

@mcpherrinm 다른 언어는 오류 처리를 위해 호출 할 때마다 해제 경로를 숨겼습니다. operator() 를 "조건부 반환 연산자"라고 부르겠습니까?

복잡성 예산에 관해서는 try! 와 구문 적으로 만 다릅니다. 적어도 불평하는 부분입니다.
try! 무거운 코드에 대한 주장이 ? 만 더 읽기 쉽게 만들까요?
그렇다면 "오류 전파 자동화 _ 전혀 _ 없음"이외의 심각한 대안이 있는지 동의합니다.

타협 제안 : https://github.com/rust-lang/rfcs/pull/1737

받아 들일 기회가 없을 수도 있지만 어쨌든 노력하고 있습니다.

"메서드 매크로"에 대한 @keeperofdakeys 의 아이디어를 좋아합니다. ? 구문은 삼항 연산자가 녹슬지 않는 것과 같은 이유로 받아 들여 져야한다고 생각하지 않습니다. ? 자체는 아무 말도하지 않습니다. 대신 "메서드 매크로"를 사용하여 ? 의 동작을 일반화 할 수있는 기능을 확인하는 것이 좋습니다.

a.some_macro!(b);
// could be syntax sugar for
some_macro!(a, b); 

a.try!();
// could be syntax sugar for
try!(a); 

이렇게하면 동작이 무엇인지 명확 해지고 쉽게 연결될 수 있습니다.

result.try!() 와 같은 메서드 매크로는 언어 인체 공학에 대한보다 일반적인 개선으로 보이며 새로운 ? 연산자보다 임시적인 느낌이 덜합니다.

@brson

나는 현재 공식을 안정화함으로써 우리가 오류 처리에서 미래의 표현성을 제한하고 있다는 다른 우려가 있습니다. 현재 결과 변환은 Rust에서 오류 처리를 원하는만큼 인체 공학적으로 만들기에 충분하지 않습니다.

이것은 흥미로운 점입니다. 이것에 집중할 가치가있을 것입니다 (아마 당신과 제가 조금 이야기를 나눌 수 있습니다). 나는 우리가 여기서 더 잘할 수 있다는 데 동의합니다. Carrier 특성에 대한 제안 된 디자인 (https://github.com/rust-lang/rfcs/issues/1718 참조)은 특히 전문화와 결합하면 상황을 더 유연하게 만들기 때문에 여기서 도움이 될 수 있습니다.

메서드 매크로가 언어에 대한 좋은 확장이 될지 의심 스럽습니다.

macro_rules! 매크로는 현재 함수를 해제하는 것과 유사한 방식으로 선언되어 있으며 새로운 임포트 시스템이 채택되면 더욱 유사해질 것입니다. 내 말은 최상위 항목처럼 선언되고 최상위 항목처럼 호출되며 곧 최상위 항목처럼 가져 오게된다는 것입니다.

이것은 방법이 작동하는 방식이 아닙니다. 메서드에는 다음과 같은 속성이 있습니다.

1. 모듈 범위에서 선언 할 수 없지만 impl 블록 내에서 선언해야합니다.
2. 직접 가져 오는 대신 impl 블록과 연결된 유형 / 특성으로 가져옵니다.
3. 이 범위에서 모호하지 않은 단일 기호를 기준으로 전달되지 않고 수신자 유형을 기준으로 전달됩니다.

유형 검사 전에 매크로가 확장되기 때문에 이러한 속성 중 어느 것도 내가 말할 수있는 한 메서드 구문을 사용하는 매크로에 해당되지 않을 수 있습니다. 물론 우리는 메소드 구문을 사용하지만 'free'매크로와 같은 방식으로 전달되고 가져 오는 매크로를 가질 수 있지만,이 차이로 인해 매우 혼란스러운 기능이 될 것이라고 생각합니다.

이러한 이유로 나는 "메소드 매크로"가 언젠가 나타날 수 있다는 믿음으로 ? 를 연기하는 것이 좋은 선택이라고 생각하지 않습니다.

더구나 일부 구조가 너무 널리 사용되고 중요해서 매크로에서 설탕으로 승격되어야하는 선이 있다고 생각합니다. for 루프가 좋은 예입니다. ? 동작은 Rust의 오류 처리 스토리에 필수적이며 매크로 대신 일류 설탕이되는 것이 적절하다고 생각합니다.

@hauleth , @CryZe

? 이 and_then 연산자 여야한다고 제안하는 사람들에게 응답하기 위해 확장 기능을 광범위하게 사용하기 때문에 Kotlin (나는 coffeescript에 익숙하지 않음)과 같은 언어에서 잘 작동하지만 그렇지 않습니다. 녹에 너무 간단합니다. 기본적으로 and_then 의 대부분의 용도는 maybe_i.and_then(|i| i.foo()) maybe_i.and_then(|i| Foo::foo(i)) . 전자는 maybe_i?.foo() 로 표현할 수 있지만 후자는 할 수 없습니다. Foo::foo(maybe_i?, maybe_j?) 가 maybe_i.and_then(|i| maybe_j.and_then(|j| Foo::foo(i, j))) 로 바뀐다 고 말할 수 있지만 이것은 단지 오류로 평가되는 첫 번째 ? 를 쳤을 때 녹이 일찍 돌아 온다고 말하는 것보다 훨씬 더 혼란 스럽습니다. 그러나 이것은 틀림없이 더 강력 할 것입니다.

@Stebalien 허용 된 RFC에서 catch { Foo::foo(maybe_i?, maybe_j?) } 는 원하는 작업을 수행합니다.

@eddyb 좋은 지적입니다. 나는 "그러나 이것은 틀림없이 더 강력 할 것이다"를 생략 할 수 있다고 생각한다. 암시 적 캐치 / 명시 적 시도 대 명시 적 캐치 / 암시 적 시도로 귀결됩니다.

let x: i32 = try Foo::foo(a?.b?.c()?));
let y: Result<i32, _> = Foo::foo(a?.b?.c()?);

대:

let x: i32 = Foo::foo(a?.b?.c()?);
let y: Result<i32, _> = catch  Foo::foo(a?.b?.c()?);

(모듈로 구문)

@Stebalien 또 다른 예 : Foo 함수에 bar 하려면 제안과 함께 다음을 수행해야합니다.

bar(Foo::foo(a?.b?.c()?)?)

이것이 당신이 염두에두고있는 것입니까? 추가 참고 ? 없이, bar 얻을 것 Result 대신의 Foo .

@eddyb 아마. 참고 : 실제로 제안하는 것이 아닙니다! ? 를 파이프 연산자로 사용하는 것은 Foo::foo(bar?) 케이스를 처리 할 방법 없이는 rust에서 특별히 유용하지 않다고 주장하고 있습니다.

제가 메서드 매크로에 대한 아이디어가 싫고 더 강력하게 반대 할 언어 기능을 생각할 수 없다는 점에 유의하십시오. 그것들은 컴파일러의 위상을 모호하게 만들고, 우리가 언어를 아주 근본적으로 변경하지 않는 한, 그것들이 존재할 수 있고 놀라운 행동을 할 방법이 없습니다. 또한 현명하게 구문 분석하기 어렵고 거의 확실히 이전 버전과 호환되지 않습니다.

@Stebalien , ? 를 파이프 연산자 Foo::foo(bar?) 하면 Foo::foo(try!(bar)) 및 bar(Foo::foo(a?.b?.c()?)?) ( Foo::foo : fn(Result<_, _>) -> Result<_, _> 라고 가정) : bar(try!(Foo::foo(a?.b?.c()?)))

@hauleth 내 요점은 Foo::foo(bar?)? 이 녹에서 bar?.foo()? 보다 _ 훨씬 _ 더 일반적이라는 것입니다. 따라서 유용하게 사용하려면 ? 가이 경우를 지원해야합니다 (또는 다른 기능을 도입해야 함). 나는 그렇게하는 방법을 가정하고 그 방법이 적어도 지저분해질 것임을 보여주었습니다. ? 의 전체 요점은 try!(foo(try!(bar(try!(baz()))))) (괄호의 2 배!)를 쓰는 것을 피할 수 있다는 것입니다. 일반적으로 try!(baz()?.bar()?.foo()) 로 다시 작성할 수 없습니다.

하지만 언제든지 다음을 수행 할 수 있습니다.

try!(baz().and_then(bar).and_then(foo))

Łukasz Niemier
[email protected]

Wiadomość napisana przez Steven Allen [email protected] w dniu 05.09.2016, o godz. 15:39 :

@hauleth https://github.com/hauleth 내 요점은 Foo :: foo (bar?)? bar? .foo ()보다 훨씬 더 일반적입니까? 녹에. 따라서 유용하게 사용하려면? 이 경우를 지원해야합니다 (또는 다른 기능을 도입해야 함). 나는 그렇게하는 방법을 가정하고 그 방법이 적어도 지저분해질 것임을 보여주었습니다. 의 전체 포인트? try! (foo (try! (bar (try! (baz ()))))) (괄호 2 배!); 일반적으로 이것을 try! (baz () ?. bar () ?. foo ())로 다시 작성할 수 없습니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/rust-lang/rust/issues/31436#issuecomment -244749275에서 보거나 https://github.com/notifications/unsubscribe-auth/ 스레드를 음소거합니다.

약간 관련이있는 메모에서,?-기능은 주로 빌더가 사용하는 것으로 보이므로 결과를 래핑하는 빌더를 구성하는 쉬운 방법을 제공하여?-기능의 필요성을 피할 수 있습니다.. 여기서 제안한 것이 있지만 조금 더 작업이 필요할 수 있습니다.

https://github.com/colin-kiegel/rust-derive-builder/issues/25

메서드 매크로 아이디어 @nrc 및 @withoutboats 에 대한 의견을 보내 주셔서 감사합니다. 작동하지 않는 구체적인 이유를 들어 주셔서 감사합니다.

@nielsle 나는 ? 가 "주로"건축업자들이 사용하고 있다고 말하는 것이 정확하지 않다고 생각합니다. 빌더는 경량의 접미사 연산자의 장점이 실제로 빛을 발하는 예라고 생각하지만 모든 상황에서 ? try! 를 선호합니다.

@nielsle 선물에 관해서는 원래 비슷한 이유로 우려했습니다. 하지만 생각해 보면 async / await 이 (가) 해당 컨텍스트에서 ? 에 대한 모든 요구를 대체 할 것이라고 생각합니다. 그들은 실제로 상당히 직교합니다. (await future)?.bar() 같은 것을 할 수 있습니다.

(키워드 await 대신 접미사 연산자를 사용하는 것이 좋을 수 있으므로 괄호가 필요하지 않습니다. 아니면 신중하게 조정 된 우선 순위로 충분할 수도 있습니다.)

우리가 안정화되기 전에 작성된 문서를보고 싶습니다. 나는 참고 문헌을 살펴 보았지만 어떤 언급도 찾을 수 없었다. 이 기능을 어디에 문서화해야합니까?

@cbreeden 나는 @steveklabnik이 일반적으로 불안정한 기능을 문서화하지 않는다는 것을 알고 있습니다. 안정화되지 않으면 시간 낭비가 될 가능성이 있기 때문입니다. 이전에 문서 작성에 대한 안정화를 차단 한 적이 있는지 모르겠습니다.

@solson 맞습니다. 여기는 아마도 그것을 제기 할 곳이 아니 었거나 적어도 안정화 질문과 관련되어서는 안됩니다. 기능 안정화를 결정할 수 있지만 안정적인 rustc로 출시되기 전에 문서화가 필요한 상황을 상상 한 것 같습니다. 문서를 기능 안정화 및 릴리스와 통합하는 것과 관련된 RFC가 있으므로 해당 프로세스가 안정화 될 때까지 기다릴 것입니다 (물론 적절한 문서가 없으면 먼저).

이 RFC의 중요한 부분은 try! 처럼 작동하는 표현식의 오른쪽 부분을 갖는 것입니다. 왜냐하면 "try"_much_의 순차 / 연쇄 사용법을 더 읽기 쉽고 "catch"를 갖도록하기 때문입니다. . 원래는 ? 를 구문으로 사용하는 100 % 서포터 였지만 최근에는 이미 ? 를 사용하는 일부 (깨끗한!) 코드를 발견하여 간단한 예제 ? 는 매우 쉽게 간과 됩니다. 이제 "새로운 시도"를위한 구문으로 ? 를 사용하는 것이 큰 실수 일 수 있다고 믿게되었습니다.

따라서 ? 또는 다른 기호 (들)를 구문으로 사용하는 것에 대한 피드백을 얻기 위해 (포럼에 대한 알림과 함께) 완료하기 전에 _ 일부 설문 조사를 올리는 것이 좋습니다 _. . 더 긴 기능에서의 사용 예와 함께 최적입니다. 다른 것을 변경하지 않으려면 ? 이름을 바꾸는 것이 좋습니다. 여론 조사는 ?! (또는 ?? ) 또는 "사용? vs. 문자보다 많이 사용"과 같이 과거에 튀어 나왔던 가능한 다른 이름을 나열 할 수 있습니다.

Btw. ? 를 사용하지 않으면 다른 언어 옵션 유형과 동일한 구문이기 때문에 싫어하는 사람들을 만족시킬 수 있습니다. 그리고 그것을 rust 옵션 유형에 대한 선택적 구문으로 만들고자하는 사람들. (이를 통해 내가 공유하는 문제가 아닙니다).

또한 이러한 설문 조사를 통해 일반적으로 RFC 프로세스에 참여하지 않는 사람들에게 도달 할 수 있다고 생각합니다. 일반적으로 이것은 필요하지 않을 수 있지만 try! => ? 은 Rust 코드를 작성하거나 읽는 모든 사람에게 매우 큰 변화입니다.

추신:
위와 같은 기능을 다양한 변형 ( "?", "?!", "??")으로 요점 을 올렸습니다. 더 있었는지 모르겠습니다. 또한이 있었다 RFC 이름 변경 ? 에 ?! 이 논의로 연결되었다.

죄송합니다. 이미 오랫동안 진행중인 토론을 다시 시작할 수 있습니다. : smiley_cat :.

( expr??? 는 모호하므로 Option에 ? 를 계속 도입하려는 경우 ?? 는 좋지 않습니다.)

? 는 매우 쉽게 간과됩니다.

여기서 무엇을 논의하고 있습니까? 완전히 강조되지 않은 코드? 정기적으로 강조 표시된 코드 검색?
아니면 함수에서 ? 을 적극적으로 찾고 있습니까?

편집기에서 ? 하나를 선택하면 _all_ 파일의 다른 ? 가 밝은 노란색 배경으로 강조 표시되고 검색 기능도 작동하므로 마지막 항목이 표시되지 않습니다. 나에게 _any_ 난이도를 제기하는 것처럼.

다른 경우와 마찬가지로 ?? 또는 ?! 끝나는 것보다 더 나은 강조 표시로이 문제를 해결하고 싶습니다.

@dathinab 나는 .try! () 또는 무언가가 더 좋을 것이라고 생각하지만 매크로에는 UFCS가 필요합니다.

let namespace = namespace_opt.ok_or(Error::NoEntry).try!();

이렇게하면 놓치기 어렵지만 .unwrap() 보다 입력하기가 더 쉽지는 않지만 간단합니다.

@eddyb : 예를 들어 github와 같은 일반 강조 코드에 관한 것입니다. 예를 들어 코드베이스를 읽을 때. 내 관점에서 볼 때 ? 를 쉽게 간과하지 않기 위해 강력한 강조 표시가 필요하면 다른 반환 경로 (/ path to catch)를 도입하고 Result<T> 에서 변수 유형을 변경할 수있는 것은 잘못된 것 같습니다 T

@CryZe : 동의하지만 가까운 시일 내에 얻을 수있을 것 같지 않습니다. 그리고 .try!() 보다 약간 짧은 것을 갖는 것도 그렇게 나쁘지 않습니다.

@CryZe 저도 그 구문을 좋아하지만 @withoutboats 는 메소드 매크로가 언어를 손상시킬 수있는 확실한 이유를 언급했습니다.
반면에 메서드 매크로가 나타나면 ? 와 잘 작동하지 않을 것이라고 생각합니다.

나는 본질적으로이시길에 두 문자를 사용하는 것에 반대하지는 않지만 예제를 살펴 보았지만 ? 이 더 이상 눈에 띄게 보이게 만든 변경 사항을 찾지 못했습니다.

그래. 일반적으로 기호는 일반 언어와 프로그래밍 언어 모두에서 구조화에 더 많이 사용되므로 일종의 키워드가 필요하다고 생각합니다.

@CryZe : 아마도 ?try 와 같은 것이 일종의 키워드 일 것입니다. 그러나 솔직히 나는 그것을 좋아하지 않는다 ( ?try ).

@eddyb

검색 기능도 작동합니다.

? 하면 오 탐지가 발생하지만 더 긴 버전은 그렇지 않을 가능성이 높습니다.

검색 중? 더 긴 버전은 그렇지 않을 것입니다.

구문 하이 라이터가이를 내부적으로 처리 할 것으로 예상합니다 (가양 성 방지). 사실, 프린지 (줄 번호 옆)에 "반환 할 수있는"마커를 삽입 할 수도 있습니다.

예를 들면

와우, 확실히 많은 도움이됩니다. 하지만 당신은 정말로 당신이
편집기를 올바르게 구성해야합니다. 항상 수행 할 수는 없습니다 (예 :
예를 들어 GitHub에서).

2016-09-15 23:52 GMT + 02 : 00 Steven Allen [email protected] :

예를 들면
[이미지 : screen-2016-09-15-175131]
https://cloud.githubusercontent.com/assets/310393/18568833/1deed796-7b6d-11e6-99af-75f0d7ddd778.png

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/31436#issuecomment -247465972,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABYmbjyrt07NXKMUdmlBfaciRZq7uBVEks5qqb4sgaJpZM4HUm_-
.

@CryZe GitHub가 오픈 소스 구문

나는 일반적으로 Rust 프로젝트가 Rust의 구문 하이 라이터가 가시성에 대한 우려의 균형을 맞추기 위해 ? 에서 매우 눈에 잘 띄는 스타일을 사용해야한다고 추천하는 것이 좋은 생각이라고 생각합니다.

나는 ? 이 우리가 여기서 할 수있는 최선의 선택이라고 생각하고, 우리는 Miri 에서 꽤 많이 사용하고 있습니다.

원래의 동기로 돌아가서 try!(...) 는 눈에 거슬 리고 오류의 흐름을 무시하고 행복한 길을 읽는 것을 어렵게 만듭니다. 이것은 전통적인 언어의 보이지 않는 예외에 비해 단점입니다. ? 를 더 관련성이 높은 키워드로 확장하면 동일한 단점이 있습니다.

반면에 ? 를 사용하면 오류의 흐름에 신경 쓰지 않으면 무시하고 백그라운드로 사라지게 할 수 있습니다. 그리고 제가 정말로 오류의 흐름에 신경을 써도 ? 는 괜찮습니다. ? 밝게 강조하는 것은 나에게도 필요하지 않지만 다른 사람들에게 도움이된다면 좋습니다. 이것은 보이지 않는 예외와 try! 둘 다에 대한 개선입니다.

?! 와 같이 사소한시길로 전환하는 것은 어떤 식 으로든 도움이되지는 않지만 오류 처리 코드를 읽고 쓰는 것은 약간 더 나빠집니다.

마지막 댓글을 작성 해주신 모든 분들께 감사드립니다 ( 이전 내부 스레드도 포함 ). 지금까지 가장 많이 언급 된 RFC에 대해 이야기하고 있다는 점을 감안할 때 안정화에 대한 논의가 활발하게 진행되고 있다는 사실에 놀랍지 않습니다.

먼저 추적을 시작하겠습니다 . @ rust-lang / lang 팀은 Result 유형의 값에 적용될 때 ? 연산자를 안정화하기로 결정했습니다. catch 기능은 안정화되지 않았으며 실제로 아직 구현되지 않았습니다. 마찬가지로, ? 를 Option 와 같은 유형으로 확장하는 수단 인 소위 "운반자 특성"은 아직 RFC 이전 논의 단계에 있습니다. 그러나 나중에 Carrier 특성을 추가 할 수 있도록 현재 구현에서 단계를 수행했습니다 (추론과의 잠재적 상호 작용에 대한 이전 우려 사항 중 일부를 해결 함).

8 월 22 일 FCP가 시작된 이후로 진행된 논의를 요약하기 위해 잠시 시간을 할애하고 싶습니다. 이러한 테마의 대부분은 원래 RFC 스레드 에서도 발생했습니다. 스레드를 읽는 데 관심이 있다면 해당 스레드의 FCP 주석 과 요약 주석 이 대화를 심도있게 다루려고 시도합니다. 어떤 경우에는이 스레드의 해당하는 것보다 더 심도있는 경우 원래 스레드의 주석에 링크 할 것입니다.

? 연산자의 범위는 현재 함수가 아닌 현재 표현식이어야합니다.

오류가 발생하면 오늘의 try! 매크로는 해당 오류를 호출 함수에 무조건 전파합니다 (즉, 오류와 함께 return 를 실행 함). 현재 설계된대로 ? 연산자는이 선례를 따르지만 사용자가 더 제한된 범위를 지정할 수 있도록 허용하는 catch 키워드를 지원합니다. 이는 예를 들어 x.and_then(|b| foo(b)) 를 catch { foo(x?) } 로 쓸 수 있다는 것을 의미합니다. 반면, ? 연산자를 사용하여 and_then 유사한 것을 의미합니다

궁극적으로 catch 가 구현되면 이것은 기본값 문제입니다 . 그리고 Rust의 ? 에 "break out of function"(사용자 정의 옵션 포함)의 기본값이 더 적절하다고 생각하는 몇 가지 이유가 있습니다.

• try! 매크로는 매우 유용한 기본값으로 여러 번 입증되었습니다 . ? 는 try! 대신 사용할 수 있으므로 동일하게 작동하는 것이 당연합니다.
• Rust의 ? 는 주로 결과 를 전파하는 데 사용되며 예외와 더 유사합니다. 모든 예외 시스템은 기본적으로 현재 함수에서 호출자에게 오류를 전파합니다 (Swift와 같이이를 위해 키워드가 필요한 시스템도 포함).
  
  
  
  • 반대로 Swift, Groovy 등의 ? 는 null 값 또는 옵션 유형과 관련이 있습니다.
  
  
  • 캐리어 트레이 트를 채택하면 Rust의 ? 연산자는 여전히 언급 된 시나리오 (특히 catch 와 함께 사용)에서 사용할 수 있지만 _main_ 사용 사례는 아닙니다.
  
  
• 오늘날 Rust에서 and_then 를 많이 사용하는 것은 메소드 표기법으로는 작동하지 않습니다 . 어떤 경우에 (미래에서와 같은) 일부 예측 된 미래 사용 은 비동기-대기 변환에 포함될 수

? 식별하기 어렵 기 때문에 제어 흐름을가립니다.

일반적인 문제는 ? 연산자가 너무 쉽게 간과된다는 것 입니다. 이것은 분명히 균형 잡힌 행동입니다. 경량 연산자를 갖는 것은 그것이 쉽게 "행복한 경로"당신이 원하는 경우에 초점을 할 수 있습니다 -하지만 오류가 (암시 적 제어 흐름을 소개 예외는 달리)가 발생할 수있는 어떤 표시를하는 것이 중요합니다. 또한 구문 강조 표시 (예 : 1 , 2 )를 통해 ? 쉽게 찾을 수 있습니다.

방법 매크로는 왜 안됩니까?

? 의 가장 큰 장점 중 하나는 수정 후 위치에서 사용할 수 있지만
foo.try! 와 같은 "메서드 매크로"에서 유사한 이점을 얻을 수 있습니다 . 사실이지만, 메서드 매크로 는 특히 메서드 처럼 동작하기를 원하는 경우 자체적으로 많은 복잡성을 열어줍니다 (예 : 어휘 범위를 사용하지 않고 수신자 유형 에 따라 전달됨). 또한 foo.try! 와 같은 메서드 매크로를 사용하면 foo? 보다 훨씬 더 무거운 무게감을 느낄 수 있습니다 (이전 요점 참조).

From 는 어떤 계약을 제공해야합니까?

원래 RFC 토론에서 우리는 [ From 대한 "계약"이 있어야하는지 여부] ((https://github.com/rust-lang/rust/issues/31436#issuecomment)에 대한 질문을 연기하기로 결정했습니다. lang 팀의 일반적인 합의 는 ? 연산자를 From 특성을 호출하는 것으로 간주 해야하며 From 특성 impls가 자연스럽게 무엇이든 할 수 있다는 것입니다. From 트레이 트의 역할은 어쨌든 여기에서 상당히 제한적이라는 점에 유의하십시오. 이것은 단순히 한 종류의 오류에서 다른 종류의 오류로 변환하는 데 사용됩니다 (하지만 항상 Result 의 컨텍스트에서

그러나 "보유자"특성에 대한 논의가 진행 중이며이 시나리오에서 강력한 관습을 채택하는 것이 더 중요하다는 점에 주목하고 싶습니다. 특히, 캐리어 트레이 트는 어떤 유형의 "성공"과 "실패"를 구성하는지, 한 종류의 값 (예 : Option )이 다른 값으로 변환 될 수 있는지 여부 (예 : Result ). 많은 사람들이 "오류 유사"유형 간의 임의의 상호 변환을 지원하지 않기를 원한다고 주장했습니다 (예 : ? 는 Option 를 Result 로 변환 할 수 없어야합니다). 분명히 최종 사용자는 자신이 선택한 유형에 대해 Carrier 특성을 구현할 수 있으므로 이는 궁극적으로 지침이지만 중요한 것입니다.

포트 시도! 사용 ?

나는 우리가 이것을 역 호환 적으로 할 수 없다고 생각하며 try! 의 구현을 그대로 두어야합니다. try! 폐기해야합니까?

@nrc 왜 이전 버전과 호환되지 않습니까?

@withoutboats try!(x) 는 (x : Result<_, _>)? 이며 우리가 _ 원한다면 그렇게 구현할 수 있지만 일반적으로 x? 는 Carrier 를 지원하는 모든 것을 추론 할 수 있습니다. 특성 (향후), 한 가지 예는 iter.collect()? 이며 try! 경우 Result 뿐이지 만 현실적으로 Option 있습니다.

말이 되네요. 나는 우리가 std에 impls를 추가하면 추론이 모호해질 수 있다는 것을 받아 들였다고 생각했습니다. 여기서도 받아들이지 않겠습니까?

어느 쪽이든, try! 는 더 이상 사용되지 않아야한다고 생각합니다.

? 컨텍스트와 같은 빌더 패턴에서 더 유용하지만 try는 컨텍스트와 같은 중첩 된 메서드에서 더 유용합니다. 나는 그것이 의미하는 바가 무엇이든 비추천되어서는 안된다고 생각합니다.

@ est31 추론을 제외하고는 지금 정확히 똑같은 일을합니다. 정확히 무엇을 의미하는지 확실하지 않지만 ? 은 일반적으로 엄격하게 더 명확합니다 (다시 모듈로 추론). 예를 들어 주시겠습니까?

@eddyb foo()?.bar()?.baz() 는 try!(try!(foo()).bar()).baz() 보다 좋으며 foo()?.bar()?.baz() try!(bar(try!(foo()))) 는 bar(foo()?)? 보다 좋습니다

두 경우 모두 ? 더 읽기 쉽습니다. 불필요한 괄호 혼란을 줄입니다.

언제 안정 상태가 될까요?

@ofek 이것은 아직 완전하지 않은 모든 것을위한 것이므로 말하기가 어렵습니다. https://github.com/rust-lang/rust/pull/36995 는 1.14에서 안정적이어야하는 기본 ? 구문을 안정화했습니다.

추가하는 것을 잊지 마세요? 이제 안정적인 참조 연산자 : https://doc.rust-lang.org/nightly/reference.html#unary -operator-expressions

그리고 @bluss 는 책이 구식이라고 지적했습니다 : https://doc.rust-lang.org/nightly/book/syntax-index.html

토 마카

나는 연장하는 것에 반대합니까? 옵션.

오류 목적으로 사용할 필요는 없습니다. 예를 들어, get 를 가져 와서 어떤 함수로 매핑하는 래퍼 메서드를 만들면 None 케이스를 전파 할 수 있기를 원합니다.

? 단지 오류에 대한 것으로 간주되었습니다. 이와 같은 일반적인 전파에 대한 더 일반적인 do 표기법은 목표가 아닙니다.

2016 년 10 월 29 일 11:08 -0400, ticki [email protected] , 작성 :

@tomaka (https://github.com/tomaka)

나는 연장하는 것에 반대합니까? 옵션.

오류 목적으로 사용할 필요는 없습니다. 예를 들어, get을 가져 와서 일부 함수로 매핑하는 래퍼 메서드를 사용한다면 None 케이스를 전파 할 수 있기를 바랍니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub (https://github.com/rust-lang/rust/issues/31436#issuecomment-257096575)에서 보거나 스레드를 음소거 (https://github.com/notifications/unsubscribe)합니다. -auth / AABsipGIpTF1-7enk-z_5JRYYtl46FLPks5q42DCgaJpZM4HUm_-).

이 (= ? 자체)는 이제 안정적인 기능입니다! (Rust 1.13부터)

두 가지 문서 문제 :

• [x] 책 # 37750의 오류 처리 장 업데이트
• [x] 현재 상황 # 37751에 대한 Carrier 트레이 트 문서 업데이트

catch 또는 Carrier 트레이 트는 아직 제대로 구현되지 않았으며, 베어 ? 기능

Carrier 이 존재하고 ? 사용할 때 오류 메시지가이를 참조하므로 Carrier 문제가 거부되는 것보다 수정 된 것이 더 좋습니다. 문서는 Option에 대해 구현되는 것을 참조하기 때문에 문서도 업데이트해야합니다. (거짓).

35946은 오류 메시지에서 Carrier 대한 언급을 제거해야합니다. 적어도 Carrier 문서에서 Option 멘션을 제거해야하는 것처럼 들립니다.

Carrier 트레이 트와의 상호 작용으로 인해이 문제에 T-libs 을 추가합니다.

@cramertj 가 만난 질문 : https://internals.rust-lang.org/t/grammatical-ambiguity-around-catch-blocks/4807

안녕하세요; # 31954에서 오류 유형에 대한 업 캐스트는 From (및 현재 head 에서도 동일)을 사용하여 수행되지만 RFC 243 에서는 변환에 Into 사용해야한다고 분명히 명시합니다.

From 가 대신 사용 된 이유가 있습니까? 일반 오류 유형 (예 : io::Error 또는 외부 크레이트의 다른 항목)으로 업 캐스트하려고 할 때 로컬 오류 유형에 대해 From 를 구현할 수 없습니다.

(RFC 243의 작성자 인 FWIW는 From 또는 Into 가 더 낫다고 생각하지 않았으며 올바른 선택을했을 수도 아닐 수도 있습니다. 질문은 RFC에 쓰여진 내용이 아닌 장점 (이 시점에서 이전 버전과의 호환성을 포함 할 수 있음)에 따라 결정되어야합니다.)

슬프게도 회귀가있을 것입니다. 없는 (적지 않은) 경우 From<...> 사용할 때 구현되는 오류 유형 인스턴스 컴파일러는 특정 경우에 타입을 추론 할 수 어디서 그것을 추론 할 수 Into 의 (세트 From 인스턴스는 현재 크레이트에 의해 제한되며 Into 인스턴스의 전체 세트는 크레이트를 컴파일하는 동안 알 수 없습니다.

참조 https://play.rust-lang.org/?gist=6d3ee9f93c8b40094a80d3481b12dd00를 (포함하는 실제 문제에서 "단순화" fmt::Error 의 SRC / librustc / 폴더의 유틸리티 / ppaux.rs # L81 )

? 를 설명하는 측면에서 이전 RFC를 대체 할 새로운 RFC가 있습니다. rust-lang / rfcs / pull / 1859

catch 블록이 이미 훨씬 더 간결 할 때 나는 -1입니다.

클로저는 흐름 제어 문을 방해합니다. ( break , continue , return )

https://github.com/rust-lang/rfcs/pull/1859 가 병합되었고이 문제를 추적 문제로 재사용한다고 주장 했으므로 catch 재평가 할 것을 제안합니다. RFC 243의

나는 우리가 철저하게 그것을 제거 것을 제안하지만, 대한 열정 아니에요 catch 그것을 위해이었다 위대한로 결코 ? 나는 그것의 가치가 있는지 여전히 빛에 의미가 있음을 만들 생각 ? 를 위해 등장했으며 Try 에 비추어 등장 할 것으로 예상되는 관용구입니다.

나는 여전히 잡기를 열망합니다. 오늘 일찍 나는 catch가 안정적이라면 피할 수있는 방식으로 코드를 수정해야했다.

이 기능은 do catch 구문으로 야간에 구현되었습니다. 그렇지 않습니까?

@withoutboats 예, catch { ... } 는 구조체 리터럴 ( struct catch { }; catch { } )과 충돌하므로 현재 do catch 입니다.
.
@archshift @SimonSapin 이 위에서 지적했듯이, 클로저는 break , continue 및 return 방해합니다.

@bstrie 요즘에는 catch 자주 원합니다. 리팩토링 중에 많이 발생합니다.

구문으로 do catch 을 (를) 요구할 계획이라는 사실을 몰랐습니다. 실제 파손의 위험이 매우 낮다는 점을 감안할 때 (둘 다 구조체 이름 지정 지침을 위반하고 생성자가 명령문의 첫 번째 표현식 (반환 위치 밖에서는 드뭅니다)이어야 함)을 고려할 때 rustfmt를 활용하여 문제가되는 식별자를 catch_ 다시 작성 하시겠습니까? 그렇게하기 위해 Rust 2.0이 필요하다면, 글쎄요, 저는 Rust 2.0이 어쨌든 사소한 변경 사항 만 포함해야한다고 항상 말하고 있습니다 ... : P

@bstrie 우리는 절대적으로 do catch 장기를 요구하고 싶지 않습니다. 현재 해당 구문을 사용하게 된 토론은 다음과 같습니다. https://github.com/rust-lang/rust/pull/39921

훌륭합니다. 컨텍스트에 감사드립니다.

나는 희망 때문에 난 그냥 여기 온 catch 된 안정, 그것을 배워야했다되지 않는 - 그래서 예, 절대적으로, 지금 ? 안정적이고, 또한 가지고 큰 것 catch .

나는 우리가 이것의 나머지 부분에 얼마나 멀리 도달했는지보고 싶었고 do catch 토론을 보았습니다.

나는 다음과 같은 경우에 도움이 될 어리석은 아이디어를 고려해 왔습니다. 선택적으로 키워드 접두사에 @ 또는 다른시길을 허용 한 다음 모든 새 키워드에시길 만 사용하도록합니다. 코 루틴 토론에서도 비슷한 문제가있었습니다. 내가 거기에 해결책으로 들어 갔는지 기억이 나지 않지만-내가 가질 수도 있지만-이것이 계속 나올 것 같습니다.

FWIW, C #은 실제로 키워드를 식별자로 사용하기 위해 @ 를 지원합니다. HTML 노드에서 속성을 설정하기 위해 new { <strong i="6">@class</strong> = "errorbox" } 와 같은 것을 전달하는 Razor에서 흔히 볼 수 있습니다.

뿡뿡
그 흥미 롭군요. 나는 그것에 대해 몰랐다. 그러나 Rust의 경우 호환성 때문에 다른 방향으로 가야합니다.

그래도 깔끔한 아이디어. .net 생태계에는 서로 다른 키워드를 사용하고 모두 서로 전화 할 수있는 많은 언어가 있습니다.

키워드의 미래에 대한 또 하나의 가능성 : 일종의 안정적인 #[feature] 같은 속성 뒤에 키워드를 배치하는 것입니다.

이 문제는 장기적으로 더 일반적인 해결책이 필요하다고 생각합니다.

@camlorn 이 스레드, 특히 Rust "epochs"에 대한 Aaron의 아이디어에 관심이있을 수 있습니다. https://internals.rust-lang.org/t/pre-rfc-stable-features-for-breaking-changes/5002

여기 문제 설명에서 https://github.com/rust-lang/rust/issues/42327 을 링크해야한다고 생각합니다. (또한 RFC 텍스트를 여기 대신 링크하도록 업데이트해야 할 수도 있습니다.)

(편집하다 : 나는 거기에 댓글을 올렸고, 누가 이미 그것을 구독했는지 확실하지 않습니다!)

@camlorn 그러나 "rustfmt는 잠시 동안 사소한 재 작성을 한 다음 키워드가됩니다"경로를 열 수 있습니다. AKA는 안정성 보장에서 "두 가지 모두에서 작동하도록 작성 될 수있는 추가 주석이 있으면 깨지지 않습니다."이스케이프 해치를 활용합니다. 그리고 추론 변경을위한 UFCS와 유사하게 가상의 "완전히 정교한 형태의 저장소"모델은 오래된 상자를 계속 작동시킬 수 있습니다.

catch 블록의 구문이 do { … } 또는 ?{ … } 라도 상관 없습니다.

do 에는 이미 키워드라는 좋은 속성이 있습니다. 그것은 과거의 사용을 멈추지 않았지만 Haskell과 같은 do -notation을 호출하는 모호한 (당신의 관점에 따라) 속성을 가지고 있으며 이것은 사용 사례에서 다소 더 가깝습니다.

그것은 또한 비슷하지만 제안 된 자바 스크립트 와 다르게 작동

이 제안은 이미 베어 블록을 표현식으로 사용하는 Rust와는 관련이 없습니다.

나는 둘 다 똑같아 보이지만 완전히 다른 일을 할 것이기 때문에 가능한 혼란을 지적했습니다.

Haskell과 유사한 do-notation을 호출하는 모호한 (당신의 관점에 따라) 속성이 있습니다.

@rpjohnst Result 및 Option은 모나드이므로 최소한 개념적으로 유사합니다. 또한 앞으로 모든 모나드를 지원하도록 확장하려면 포워드 호환이 가능해야합니다.

맞습니다. 과거에는 모나드와 개념적으로 유사한 것에 do 를 추가하면 완전히 지원하지 않으면 사람들을 슬프게 할 것이라는 이의가있었습니다.

동시에, 전체 do-notation과 포워드 호환이 가능하도록 만들 수 있지만 전체 do-notation을 추가 해서는 안됩니다 . if / while / for / loop 또는 break / continue /와 같은 제어 구조로는 구성 할 수 없습니다. return , catch (또는이 경우 do ) 블록 내부 및 전체 에서 사용할 수 있어야합니다. (이것은 전체 do-notation이 고차 함수 측면에서 정의되고 catch 블록의 내용을 일련의 중첩 된 클로저에 채우면 갑자기 모든 중단 흐름을 제어하기 때문입니다.)

그래서 결국 이러한 단점 do 실제로있는 DO-표기없이 할 표기법과 같은 및 DO-표기법이되기 위해 앞으로 좋은 경로 않고 있다는 점이다. 개인적으로 나는 Rust가 어쨌든 do 표기법을 얻지 않을 것이기 때문에 이것으로 완전히 괜찮습니다. 그러나 그것은 혼란입니다.

@nikomatsakis , #

catch 키워드를 문맥에 맞게 만들 수 있지만 struct catch 이 범위 내에 있으면 비활성화하고 지원 중단 경고를 발행 할 수 있습니까?

이것이 얼마나 적절한 지 확실하지 않지만 종종 원하는 경우 return 를 사용할 때 현재 가능한 오류 값이 아닌 ok를 중단하려는 경우가 있다는 점에서 해결할 필요가있는 문제가 발생했습니다. _outer_ ok를 통해 _inner_ 오류를 중단합니다. say 함수가 Option<Result<_,_>> 를 반환 할 때와 같이 반복자에서 흔히 볼 수 있습니다.

특히 지금 당장 많이 사용하는 프로젝트에 매크로가 있습니다.

macro-rules! option_try {
    ( $expr:expr ) => {
        match $expr {
            Ok(x)  => x,
            Err(e) => return Some(Err(e.into())),
        }
    }
}

Iterator::next 구현 내에서 호출 된 함수가 실패시 Some(Err(e)) 와 함께 즉시 중단되어야하는 것은 매우 일반적입니다. 이 매크로는 일반 함수 본문 내부에서 작동하지만 catch 블록 내부에서는 작동하지 않습니다. catch는 범주 적으로 return 가져 오지 않고 특수한 ? 구문

결국 레이블 반환은 전체 catch 블록 아이디어를 중복되게 만들 것이지만 그렇지 않습니까?

# 41414가 완료된 것 같습니다. 누군가 OP를 업데이트 할 수 있습니까?

업데이트 : RFC rust-lang / rfcs # 2388이 이제 병합되었으므로 catch { .. } 는 try { .. } 로 대체됩니다.
이 댓글 바로 위에있는 추적 문제를 참조하세요.

이것이 2015 년판에서 의미하는 바는 do catch { .. } 구문이 여전히 안정화 과정에있는 것입니까? 아니면 2018 년판 이상에서 try { .. } 를 통해서만 삭제되고 지원됩니까?

@ Nemo157 후자.

현재 제안서에 try ... catch ... 두 개 문이 있습니까? 그렇다면 의미를 얻지 못합니다.

어쨌든,이 제안이 단지 탈당에 관한 것이라면 나는 그것에 대해 멋지다. 즉, catch 블록은 ? 연산자가 종료하는 위치를 변경합니까?

모든 확인란이 상단 게시물에 표시되어 있으므로 언제 앞으로 나아갈까요? 여전히 해결되지 않은 문제가있는 경우 새 확인란을 추가해야합니다.

기록되지 않은 해결되지 않은 질문이 많이 남아있을 것입니다.
예를 들어 ok-wrapping 동작이 lang 팀 내에서 해결되지 않고 Try 의 디자인이 완료되지 않는 등의 작업이 진행됩니다. 이 문제는 유용성보다 오래되었을 가능성이 있으므로이 문제를 더 많은 목표를 가진 여러 문제로 분할해야합니다.

흠 ..이 질문이 기록되지 않았다는 것이 저를 괴롭 힙니다.

@ mark-im 그래서 명확히하기 위해 그들이 어딘가에 있었다고 생각합니다; 그러나 한 위치에는 없습니다. 다양한 RFC 및 문제 등에 약간 흩어져있는 atm이므로 적절한 위치에 기록해야합니다.

지원 특성의 디자인은 https://github.com/rust-lang/rust/issues/42327 에서 추적됩니다

그래서 저는 여기에 try{} 만 남았고, 제가 아는 유일한 불일치는 RFC에서 해결되고 위에서 언급 한 문제 중 하나에서 재확인 된 것입니다. 그래도 뚜렷한 추적 문제가있는 것이 좋습니다.

아직 수행해야하는 보류중인 구현 작업에 대한 확인란을 추가하겠습니다.

나는 @joshtriplett합니다 (에서 언급 OK-포장에 대한 우려가 있었다 알고 @scottmcm try RFC를) 나는 개인적으로 같은 제한 할 것 break 의 초기 안정화에 try { .. } 그렇게 loop { try { break } } 등을 할 수 없습니다.

센트릴

loop { try { break } } 할 수 없도록

지금 당장은 비 루프 블록에서 break 를 사용할 수 없으며 정확합니다. break 는 루프에서만 사용해야합니다. try 블록을 일찍 떠나려면 표준 방식은 Err(e)? 입니다. 그리고 그것은 초기 잎이 항상 "비정상적인"통제 경로에 있도록 강제합니다.

따라서 내 제안은 표시된 코드가 허용되어야하며 try 떠나는 것이 아니라 loop 깨야합니다.

즉각적인 이점은 break 가 표시 될 때 루프에서 중단된다는 것을 알 수 있으며 항상 continue 바꿀 수 있다는 것입니다. 또한 try 내부에서 loop try 블록을 사용하고 루프를 종료하려는 경우 중단 점에 레이블을 지정할 필요가 없습니다.

@Centril 키워 주셔서 감사합니다.

break 에 관해서는 개인적으로 try 는 break 에 대해 신경 쓰지 않고 포함하는 루프를 통과한다고 간단히 말하면 괜찮을 것입니다. break 이 try 와 (과) 상호 작용하는 것을 전혀 원하지 않습니다.

Ok -wrapping의 경우 예, try 을 (를) 안정화하기 전에이 문제를 해결하고 싶습니다.

@centril 예, 알고 있습니다. 그러나 그 문제를 제기 다시 재있어 것을 기억하는 것이 중요합니다. RFC 는 그것을 갖기로 결정했고 그것 없이 구현되었지만 원래 의도는 _again_ 취해졌고 구현은 RFC를 따르도록 변경되었습니다. 그래서 저의 큰 질문은 중요한 사실이 변경되었는지 여부입니다. 특히 이것이 RFC + IRLO에서 논의한 것 중 가장 시끄러운 주제 중 하나라는 점을 감안할 때.

@scottmcm 물론 아시다시피, 저는 Ok -wrapping;) 유지에 동의하며 문제가 해결 된 것으로 간주되어야한다는 데 동의합니다.

나는 이것이 옳은지 확실하지 않은 것에 대해 언급하고 싶었습니다.

본질적으로 내가 가진 상황은 GUI 프레임 워크의 콜백입니다. Option 또는 Result 를 반환하는 대신 UpdateScreen 를 반환해야합니다. 업데이트가 필요합니다. 종종 나는 로깅이 전혀 필요하지 않으며 (모든 사소한 오류에 로그온하는 것은 실용적이지 않음) 오류가 발생하면 UpdateScreen::DontRedraw 를 반환합니다. 그러나 현재 ? 연산자를 사용하면 항상 다음과 같이 작성해야합니다.

let thing = match fs::read(path) {
    Ok(o) => o,
    Err(_) => return UpdateScreen::DontRedraw,
};

Try 연산자를 통해 Result::Err 에서 UpdateScreen::DontRedraw 로 변환 할 수 없기 때문에 이것은 매우 지루해집니다. 종종 실패 할 수있는 해시 맵에서 간단한 조회를합니다 (오류가 아닙니다. )-너무 자주 하나의 콜백에서 ? 연산자를 5-10 번 사용했습니다. 위에서 쓰기에 매우 상세하기 때문에, 내 현재의 솔루션이다 impl From<Result<T>> for UpdateScreen 과 같이 , 다음과 같이 콜백에서 내부 함수를 사용

fn callback(data: &mut State) -> UpdateScreen {
     fn callback_inner(data: &mut State) -> Option<()> {
         let file_contents = fs::read_to_string(data.path).ok()?;
         data.loaded_file = Some(file_contents);
         Some(())
     }

    callback_inner(data).into()
}

콜백이 함수 포인터로 사용되기 때문에 -> impl Into<UpdateScreen> 사용할 수 없습니다 (어떤 이유로 impl 반환하는 것은 현재 함수 포인터에 대해 허용되지 않습니다). 그래서 제가 Try 연산자를 사용하는 유일한 방법은 내부 함수 트릭을 수행하는 것입니다. 다음과 같이 간단히 할 수 있다면 좋을 것입니다.

impl<T> Try<Result<T>> for UpdateScreen {
    fn try(original: Result<T>) -> Try<T, UpdateScreen> {
        match original {
             Ok(o) => Try::DontReturn(o),
             Err(_) => Try::Return(UpdateScreen::DontRedraw),
        }
    }
}

fn callback(data: &mut State) -> UpdateScreen {
     // On any Result::Err, convert to an UpdateScreeen::DontRedraw and return
     let file_contents = fs::read_to_string(data.path)?;
     data.loaded_file = Some(file_contents);
     UpdateScreen::Redraw
}

현재 제안에서 이것이 가능할지 확실하지 않으며 고려할 사용 사례를 추가하고 싶었습니다. 커스텀 Try 연산자가 이와 같은 것을 지원할 수 있다면 좋을 것입니다.

편집하다:
제가 실수를.

이 게시물 무시

유형 추론으로 더 잘 작동 할 수 있습니까? 간단한 경우에도 실패합니다.

fn test_try(a: u32, b: u32) {
    let div = if b != 0 {
        Some(a / b)
    } else {
        None
    };

    let x // : Option<_> // why is this type annotation necessary
    = try { div? + 1 };

    println!("{:?}", x);
}

try 블록 대신 클로저를 사용하도록 다시 작성하면 (그리고이 과정에서 느슨한 자동 래핑),

fn test_closure(a: u32, b: u32) {
    let div = if b != 0 {
        Some(a / b)
    } else {
        None
    };

    let x =  (|| (div? + 1).into())();

    println!("{:?}", x);
}

유형 어노테이션이 필요하지 않지만 결과를 래핑해야합니다.

운동장

@KrishnaSannasi 클로저 기반 예제에는 Into 가 출력을 제한하지 않고 나중에 수행하는 곳에서는 사용하지 않기 때문에 유형 추론 실패 ( playground )도 있습니다.

이것은 try 블록이 아닌 Try 트레이 트의 문제인 것 같습니다. Into 와 유사하게 입력에서 출력으로 어떤 유형 정보도 전파하지 않습니다. 출력 유형은 나중에 사용하여 결정할 수 있어야합니다. https://github.com/rust-lang/rust/issues/42327 에 특성에 대한 _ 많은 _의 토론이 있습니다. 아직 읽지 않았기 때문에이 문제를 해결할 수있는 제안이 있는지 확실하지 않습니다.

헉헉

예, 코드를 사용하기 위해 마지막 순간에 코드를 변경했지만 테스트하지 않았습니다. 내 잘못이야.

try 블록 안정화에서 얼마나 멀리 떨어져 있습니까? 그것은 내가 야간에서 필요한 유일한 기능입니다 : D

아 리그 니르

일단 이것이 끝나면 안정 될 수 있다고 믿습니다.

블록 try {} catch (또는 기타 후속 ID)를 사용하여 미래를 위해 디자인 공간을 열어두고 대신 매치로 원하는 작업을 수행하는 방법을 알려줍니다.

현재 기능을 허용하면서 미래를 위해 디자인 공간을 열어 둘 수있는 가능성을 허용하는 중간 디자인이 없습니까 (따라서 결국 catch 블록)?

내가 만든 PR은 어쨌든 그 상자를 체크해야합니다. CC @nikomatsakis

나는 어제 처음으로 이것을 사용해 보았고 이것이 조금 놀랐습니다.

#![feature(try_blocks)]
fn main() -> Result<(), ()> {
    let x: () = try {
        Err(())?
    }?;
    Ok(x)
}

때문에 컴파일되지 않습니다

error[E0284]: type annotations required: cannot resolve `<_ as std::ops::Try>::Ok == _`

차라리 나는해야했다

#![feature(try_blocks)]
fn main() -> Result<(), ()> {
    let x: Result<(), ()> = try {
        Err(())?
    };
    let x = x?;
    Ok(x)
}

대신.

처음에는 혼란 스러웠으므로 오류 메시지를 변경하거나 --explain ?

첫 번째 예에서 물음표를 약간 아래로 이동하면

#![feature(try_blocks)]
fn main() -> Result<(), ()> {
    let x: () = try {
        Err(())?
    };
    Ok(x?)
}

더 나은 오류 메시지가 표시됩니다. 이 오류는 Rust가 try { ... } 를 해결할 유형을 결정할 수 없기 때문에 발생합니다. 이 유형을 해결할 수 없기 때문에 <_ as Try>::Ok 유형이 무엇인지 알 수 없으므로 오류가 발생했습니다. (때문에 ? 오퍼레이터가 언랩 Try 유형과 배면 제공 Try::Ok 유형). Rust는 자체적으로 Try::Ok 유형으로 작동 할 수 없습니다. Try 특성과 해당 특성을 구현하는 유형을 통해 해결되어야합니다. (현재 유형 검사가 작동하는 방식의 제한 사항)

이 기능에 대한 모든 것이 구현되었습니다. 맞습니까? 만약 그렇다면, 안정되기 전에 얼마나 오래 앉아보아야할까요?

나는 이것이 우리가 이것을 원하는지 여부에 대한 열린 질문이라고 생각했습니다. 특히 여기서 예외 언어 (try, catch)를 사용할 것인지에 대한 논의가있었습니다.

개인적으로 저는 Rust가 예외와 같은 것을 가지고 있다는 인상을 주려는 시도를 강력히 반대합니다. 특히 catch 라는 단어의 사용은 예외가있는 언어에서 온 모든 사람이 이것이 풀린다 고 가정 할 것이기 때문에 나쁜 생각이라고 생각합니다. 가르치는 것이 혼란스럽고 고통 스러울 것으로 예상합니다.

특히 여기서 예외 언어 (try, catch)를 사용할 것인지에 대한 논의가있었습니다.

나는 https://github.com/rust-lang/rfcs/pull/2388이 try 이름이 허용되는지 여부를 확실히 결정했다고 생각합니다. 이것은 공개 된 질문이 아닙니다. 그러나 Try 특성과 Ok -wrapping의 정의가있는 것 같습니다.

Ok 래핑은 원래 RFC에서 이미 결정된 후 구현 중에 제거되고 나중에 다시 추가되었습니다. 나는 그것이 어떻게 열린 질문인지 모르겠습니다.

@rpjohnst 글쎄요, 원래 RFC의 결정에 동의하지 않는 Josh의 덕택입니다 ... :) 그것은 저에게 해결 된 문제 https://github.com/rust-lang/rust/issues/31436#issuecomment -427096703, https://github.com/rust-lang/rust/issues/31436#issuecomment -427252202 및 https : //를 참조 하세요 . github.com/rust-lang/rust/issues/31436#issuecomment -437129491. 어쨌든 ... 내 의견의 요점은 "예외 언어"로서 try 가 해결 된 문제라는 것입니다.

와우, 언제 이런 일이 있었나요? 마지막으로 기억 나는 것은 내부에 대한 토론이었습니다. 나는 Ok-wrapping에 매우 반대합니다.

으으. 이런 일이 일어났다는 것을 믿을 수 없습니다. Ok 랩핑은 너무 끔찍합니다 (함수의 모든 반환 표현식이 함수의 반환 유형이어야한다는 매우 현명한 직관을 깨뜨립니다). 네, 확실히 @ mark-im과 함께합니다. Josh의 의견 불일치가이 문제를 공개 된 문제로 유지하고 더 많은 토론을 할 수있을만큼 충분한가요? 팀원이 아니라는 의미가 아니라이 문제를 해결하는 데 도움을 드리고 싶습니다.

Ok RFC 243에 접수로 -wrapping (문자로 정의 된 ? 이 언제 일어 났는지 궁금해 경우, 운전자가) 함수 반환 식 '유형에 대한되지 변경 아무것도 않습니다. 이것이 RFC 243이 정의한 방법입니다 : https://github.com/rust-lang/rfcs/blob/master/text/0243-trait-based-exception-handling.md#catch -expressions

이 RFC는 ? 연산자를 "범위 지정"하는 데 사용되는 catch {..} 표현식 양식도 도입합니다. catch 연산자는 관련 블록을 실행합니다. 예외가 발생하지 않으면 결과는 Ok(v) 이며 여기서 v 는 블록의 값입니다. 그렇지 않고 예외가 발생하면 결과는 Err(e) 입니다.

catch { foo()? } 는 본질적으로 foo() 와 동일합니다.

즉, T 유형의 블록을 가져와 무조건 래핑하여 Result<T, _> 유형의 값을 생성합니다. 블록에있는 return 문은 완전히 영향을받지 않습니다. 블록이 함수의 꼬리 표현식 인 경우 함수는 Result<T, _> 반환해야합니다.

연령대에 따라 야간에 이러한 방식으로 구현되었습니다 : https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=88379a1607d952d4eae1d06394b50959. 이것은 lang 팀이이 스레드에서 많은 토론을 한 후 수행되었으며 다음 스레드에서 연결되었습니다. rust-lang / rust # 41414 (이 문제의 상단에도 링크되어 있습니다).

2019 년 5 월 28 일 오후 5:48:27 PDT에 Alexander Regueiro [email protected]이 작성했습니다.

으으. 이런 일이 일어났다는 것을 믿을 수 없습니다. Ok 포장이 너무 끔찍합니다.
모든 표현을 반환하는 매우 현명한 직관을 깨뜨립니다.
함수는 함수의 반환 유형이어야합니다). 그래, 확실히
@ mark-im과 함께. 조쉬의 의견 차이가
문제를 열고 그것에 대해 더 많은 토론을 얻습니까? 기꺼이 그를 지원하겠습니다
이 싸움에서 팀원이 아니라는 의미가 아닙니다.

감사합니다. 나는 나 자신을 위해서만 이것에 동의하지 않습니다. 나는 또한 내가 본 것과 같은 입장을 표현한 수많은 사람들을 대표하고있다.

트윗 담아 가기

Ok 랩핑이 그렇게 동의하지 않는 이유를 설명하거나 이전에 설명 된 링크를 제공 할 수 있습니까? 나는 보러 갔지만 피상적으로보기에는 아무것도 보지 못했다. 나는 이것에 말이 없습니다 (나는 모든 상자 체크를 보았고 한 달 동안 토론이 없었기 때문에 이것에 대해 말 그대로 언급했습니다). 그러나 이제이 말벌의 둥지를 걷어 찼으므로 나는 논쟁을 더 잘 이해하고 싶습니다.

2019 년 5 월 28 일 화요일 오후 03:40:47 -0700 Russell Johnston은 다음과 같이 썼습니다.

Ok 래핑은 원래 RFC에서 이미 결정된 후 구현 중에 제거되고 나중에 다시 추가되었습니다. 나는 그것이 어떻게 열린 질문인지 모르겠습니다.

나는 당신이 당신 자신의 질문에 부분적으로 대답했다고 생각합니다. 나는 모두를 생각하지 않는다
원래 RFC 토론에 참여한 내용은 같은 페이지에있었습니다. try
절대적으로 많은 사람들이 원했지만 합의가 없었습니다.
Ok-wrapping을 위해.

2019 년 5 월 28 일 화요일 03:44:46 PM -0700에 Mazdak Farrokhzad는 다음과 같이 썼습니다.

어쨌든 ... 내 의견의 요점은 "예외 언어"로서 try 가 해결 된 문제라는 것입니다.

설명하자면 "예외"라는 은유가 매력적이라고 ​​생각하지 않습니다.
try-fn 및 Ok-wrapping과 같은 많은 시도는
예외와 같은 메커니즘을 가진 가짜 언어를 만들려고합니다.
하지만 try 자체는 다른 곳에서 ? 를 잡는 수단으로
함수 경계는 제어 흐름 구조로 이해됩니다.

2019 년 5 월 28 일 화요일 오후 11:37:33 -0700에 Gabriel Smith는 다음과 같이 썼습니다.

Ok 포장이 그렇게 마음에 들지 않는 이유를 설명해 주시겠습니까?

몇 가지 이유 중 하나 :

2019 년 5 월 28 일 화요일 오후 05:48:27 -0700 Alexander Regueiro는 다음과 같이 썼습니다.

함수의 모든 반환 표현식이 함수의 반환 유형이어야한다는 매우 현명한 직관을 깨뜨립니다.

이것은 사람들이 유형 지향 추론에 사용하는 다양한 접근 방식을 깨뜨립니다.
기능 및 코드 구조에 대해.

나는 확실히 여기에 내 생각이 있지만 지금 당장이 주제를 다시 열지 않겠습니까? 구문에 대해 500 개 이상의 게시물에 대한 논쟁이 있었기 때문에 잠시 동안 지뢰를 피하고 싶습니다.

이 문제를 논의하는 lang 팀에서 차단 된 경우 "catch 블록이 결과 값을"래핑 "해야하는지 확인 (# 41414)"확인란을 다시 선택 취소해야합니다 (언어 팀에서 차단되었다는 주석과 함께). 이 추적 문제가 상태를 알고 있습니까?

죄송합니다. 저는 아무것도 다시 열지 않습니다. 추적 문제에서 결정된 것으로 표시된 내용과 그 발생시기 + 어떻게 발생했는지 다시 설명합니다.

@rpjohnst 정보 주셔서 감사합니다!

@yodaldevoid Josh는 내 생각을 거의 요약했습니다.

나는 블록에 국한된 ok-wrapping (함수 유형에 영향을주는 것과는 반대로)에 대해 약간 덜 반대하지만 여전히 나쁜 선례를 설정한다고 생각합니다. Josh가 말한 것처럼 "예외의 은유가 매력적이라고 ​​생각하지 않습니다."

@joshtriplett 은 본질적으로 내 견해도 요약했습니다. 문제는 "예외"은유 (분명히 패닉 + catch_unwind 가 훨씬 더 분석적임)와 유형 기반 추론의 적합성입니다. 범위 지정 및 제어 흐름 메커니즘으로 try 블록도 괜찮지 만 더 급진적 인 요점은 아닙니다.

좋아요, 충분히 공평합니다. 여기서 전체 토론을하지 않겠습니다. 제안 된대로 상자를 선택 취소하고이 스레드에 언급 된 몇 가지 근거를 사용하여 lang-team 토론에 다시 넣으시겠습니까? 안정화가 서두르지 않는 한 그것은 합리적이라고 생각합니다.

유형 주석에 대한 구문이 합의 되었습니까? 나는 try { foo()?; bar()?; }.with_context(|_| failure::err_msg("foon' n' barn'")?; 기대하고 있었는데, 이는 컴파일에 원격으로 관심이없는 error[E0282]: type annotations needed .

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=4e60d44a8f960cf03307a809e1a3b5f2

나는 조금 전에 주석을 읽었지만 (그리고 github에 300 개의 주석을 다시로드하는 것은 너무 지루합니다), Try::Ok 랩핑이 Ok 사용한 논쟁에 관한 대부분의 예제 (모두는 아니더라도)를 기억합니다. 예제에서 Option Try 를 구현하는 것을 고려할 때, 이것이 토론의 어느 쪽에서 팀의 입장에 어떤 영향을 미치는지 알고 싶습니다.

Rust를 사용할 때마다 "man, 나는 정말로 여기에 try 블록을 사용할 수 있으면 좋겠다"라고 생각하지만, 그 시간의 약 30 %는 Option s에 try를 사용할 수 있기를 바랍니다. 저는 Scala에서 사용했는데, 일반적으로 for 구문을 사용하여 모나드에 적용했지만 여기서는 try 와 매우 유사합니다.

바로 오늘, 저는 json 크레이트를 사용하고 있었고 옵션을 반환하는 as_* 메서드를 노출합니다.

두 가지 구문을 사용하면 내 예는 다음과 같을 것입니다.

match s {
  "^=" => |a, b| try { a.as_str()?.starts_with(b.as_str()?) }.unwrap_or(false),
  "$=" => |a, b| try { Some(a.as_str()?.ends_with(b.as_str()?)) }.unwrap_or(false),
  // original
  "$=" => |a, b| {
    a.as_str()
      .and_then(|a| b.as_str().map(|b| (a, b)))
      .map(|(a, b)| a.starts_with(b))
      .unwrap_or(false)
    },
}

문맥 상 반환 유형이 Option 인지 Result 인지 여부는 매우 명확하고 코드 이해력이있는 한 실제로 중요하지 않다고 생각합니다. 투명하게 의미는 분명합니다. "이 두 가지가 유효한지 확인하고 작업을 수행해야합니다." 이 함수 중 하나를 선택해야한다면 첫 번째를 선택하겠습니다. try 처럼이 함수가 더 큰 컨텍스트에 포함되어 있다고 생각할 때 이해의 손실이 없다고 생각하기 때문입니다. 항상.

내가 처음이 글을보기 시작했을 때 나는 명시적인 것이 더 낫겠다고 생각했기 때문에 Ok 래핑에 반대했지만 그 이후로 "나는 여기에서 try 블록을 사용할 수 있습니다. "라는 결론에 도달했습니다. Ok -wrapping이 좋습니다.

나는 원래 마지막 문장이 Try 을 구현하는 유형을 반환하는 함수 인 경우 Ok 래핑이 더 낫다고 생각했지만 구문의 차이는 다음과 같습니다.

try {
  fallible_fn()
}

try {
  fallible_fn()?
}

이 경우 다시 Ok -wrapping이 더 낫다고 생각합니다. fallible_fn 가 Try 반환 함수라는 것을 분명히하기 때문에 실제로는 더 명시 적입니다.

나는 야당이 이것에 대해 어떻게 생각하는지 알고 싶습니다. 그리고이 스레드에서 많은 다른 사람들을 볼 수 없기 때문에 @joshtriplett.

편집 : 나는 인체 공학 / 독해 관점에서만 이것을보고 있다고 언급해야합니다. 더 쉬운 추론과 같은 구현 측면에서 하나가 다른 것보다 기술적 장점이 더 많은지 모르겠습니다.

중첩 된 Option 구문 분석에도 try 기회를주고 싶었습니다.

#![feature(try_blocks)]

struct Config {
    log: Option<LogConfig>,
}

struct LogConfig {
    level: Option<String>,
}

fn example(config: &Config) {
    let x: &str = try { config.log?.level? }.unwrap_or("foo");
}

이것은 실패합니다

error[E0282]: type annotations needed
  --> src/lib.rs:12:19
   |
12 |     let x: &str = try { config.log?.level? }.unwrap_or("foo");
   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type
   |
   = note: type must be known at this point

내가 얻은 가장 가까운 것은

fn example(config: &Config) {
    let x: Option<&str> = try { &**config.log.as_ref()?.level.as_ref()? };
    let x = x.unwrap_or("foo");
}

as_ref 은 매우 유감입니다. 나는 Option::deref 이 여기에 도움이 될 것이라는 것을 알고 있지만 충분하지 않습니다. 이것은 어떻게 든 인간 공학 (또는 관련 아이디어)과 일치 해야하는 것처럼 느껴집니다.

여러 줄도 안타깝습니다.

try Result 는 정수 리터럴처럼 @shepmaster 의 첫 번째 시도가 Result<&str, NoneError> 추론하도록 할까요 ? ? s에 대해 변환 할 공통 오류 유형을 찾을 수있는 나머지 문제는 무엇입니까? (어딘가에 대한 논의를 놓친 적이 있습니까?)

@shepmaster 유형 추론에 동의합니다. 충분히 재미있게, 그러나, 나는 다소 순진한으로 정확한 코드를 시도 try_ 구현과 잘 작동 : https://github.com/norcalli/koption_macros/blob/4362fba8fa9b6c62fdaef4df30060234381141e7/src/lib.rs#L23

    let x = try_! { config.log?.level? }.unwrap_or("foo".to_owned());
    assert_eq!(x, "debug");

잘 작동합니다.

다소 순진한 try_ 구현

네,하지만 매크로 호출은 반환 String 가 아니라 &str , 필요 소유권을. 주변 코드를 표시하지 않지만 Config 소유권이 없기 때문에 실패합니다.

fn example(config: &Config) {
    let x = try_! { config.log?.level? }.unwrap_or_else(|| String::from("foo"));
}

error[E0507]: cannot move out of captured variable in an `Fn` closure
  --> src/lib.rs:20:21
   |
19 | fn example(config: &Config) {
   |            ------ captured outer variable
20 |     let x = try_! { config.log?.level? }.unwrap_or_else(|| String::from("foo"));
   |                     ^^^^^^^^^^ cannot move out of captured variable in an `Fn` closure

또한 무조건 String 할당합니다. 이 예에서는 비 효율성을 피하기 위해 unwrap_or_else 를 사용했습니다.

이 기능이 async/await 블록 이전에 안정화되지 않은 것은 유감입니다. IMO는 더 일관되었을 것입니다.

let fut = async try {
    fut1().await?;
    fut2().await?;
    Ok(())
};

try 없이 작동하도록 허용하는 대신. 그러나 나는 그 배가 항해 한 지 오래되었다고 생각합니다.

Re : 자동 래핑, 지금은 async 블록과 일치하는 것이 가능하지 않을 것이라고 생각합니다. async 블록은 Future 구현하는 익명 유형으로 일종의 "자동 래핑"을 수행합니다. 그러나 이것은 try 블록으로는 불가능한 조기 수익에서도 마찬가지입니다.

가상의 async try 블록이 있다면 두 배로 혼란스러워 질 수 있습니다. 결과 를 자동 래핑해야합니까?

나는 우리가 자동 포장 의미에서 일관성에 대한 기회를 잃지 않았다고 생각합니다. 모두 async 블록 기능을 사용할 수 있습니다 ? , 모두 자신의 설명서를 수행해야합니다 Ok -wrapping, 모두 초기 및 최종 수익을.

반면에 try 블록은 자동 Ok 랩핑과 함께 ? 를 사용할 수 있습니다. 예 를 들어 조기 반환 기능 (아마도 레이블 중단)을 가정 하는 "조기 반환"을 포함 합니다. value . 가상의 try 함수 는 초기 및 최종 수익 모두에서 자동 Ok 랩핑을 쉽게 수행 할 수 있습니다.

가상의 async try 블록은 단순히 두 개의 auto- Ok -wrap과 auto- Future -wrap의 기능을 결합 할 수 있습니다. (다른 방법은 구현이 불가능하며 어쨌든 try async 로 작성됩니다.)

내가 보는 불일치는 async 블록을 함수로 병합했다는 것입니다. (이것은 더 적은의 RFC에 마지막 순간 반대에서 일어나지 않았다.)이 의미가 있다는 것입니다 무엇 return 에서 async 블록, 블록을 종료하는 동안 return 에서 try 블록은 포함 함수를 종료합니다. 그러나 이것들은 적어도 분리 된 상태에서 의미가 있으며, 조기 반환 또는 레이블 중단 값이없는 async 블록은 사용하기 훨씬 더 어려울 것입니다.

이것의 안정화를 멈추는 것이 있습니까? 아니면 아직 아무도 시간을 할애하지 않았습니까? 그렇지 않으면 필요한 PR을 만드는 데 관심이 있습니다 🙂

2019 년 11 월 18 일 오전 2:03:36 PST에 Kampfkarren [email protected]이 작성했습니다.

이것의 안정화를 멈추거나 아무도
아직 할 시간이야? 필요한 PR을 만드는 데 관심이 있습니다.
그렇지 않으면 🙂>
>
->
당신이 멘션 되었기 때문에받은 것입니다.>
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.>
https://github.com/rust-lang/rust/issues/31436#issuecomment -554944079

예, 안정화 차단제는 Ok-wrapping 결정을 통해 작동합니다. 어떻게 작동해야하는지에 대한 합의가있을 때까지 안정화되어서는 안됩니다.

개인적으로 Ok-wrapping에 반대하지만 사후에 추가하는 것이 얼마나 어려울 지 궁금합니다. no-ok-wrapping forward는 ok-wrapping과 호환됩니까?

Result<Result<T,E>> 의 모호함과 같은 까다로운 경우를 상상할 수 있지만 이러한 모호한 경우에는 랩핑 없음으로 돌아갈 수 있습니다. 사용자는 명확하게 확인하기 위해 명시 적으로 Ok-wrap 할 수 있습니다. 그렇게 나쁘지 않은 것 같습니다. 이런 종류의 모호함이 너무 자주 나타날 것으로 예상하지 않기 때문입니다 ...

Ok 강압이 아니라 Ok -wrapping이기 때문에 모호함이 전혀 없어야합니다. try { ...; x } 얻을 것이다 Ok(x) 만큼 명확하게 같은 Ok({ ...; x }) .

@joshtriplett 미해결입니까? 추적 문제에는 https://github.com/rust-lang/rust/issues/41414를 인용하여 resolve whether catch blocks should "wrap" result value 이 선택되어 있습니다.

@rpjohnst 죄송합니다. 더 명확해야했습니다. 내 말은 Ok-wrapping없이 지금 try 안정화했다면 나중에 역 호환 적으로 추가 될 수 있다고 믿습니다.

즉, 대부분의 사람들은 우리가 try 블록을 가져야한다는 데 동의하지만 모든 사람이 catch 또는 ok-wrapping에 동의하는 것은 아닙니다. 하지만 나는 그러한 토론이 try 를 차단할 필요가 없다고 생각합니다 ...

@Kampfkarren 네. 위의 대화는이 문제의 진행 상황을 자세히 설명합니다. 모든 사람에게 완전히상의하지 않고 조기에 확인되었습니다. 특히 @joshtriplett 은 다른 사람들 (나 자신을 포함)이 공유 한 우려를 가지고있었습니다.

@ mark-im 앞으로 Ok-wrapping이 추가되는 것을 정확히 어떻게 보십니까? 나는 그것이 어떻게 될 수 있는지 알아 내려고 노력하고 있지만 그것을 잘 볼 수 없습니다.

그래서 나는 그것이 좋은 생각인지 아닌지 모르겠다 고 말하면서 이것을 서두에 둘 것입니다.

우리는 ok-wrapping없이 try 블록을 안정화시킬 것입니다. 예를 들면 :

let x: Result<usize, E> = try { 3 }; // Error: expected Result, found usize
let x: Result<usize, E> = try { Ok(3) }; // Ok (no pun intended)

나중에 Ok-wrapping이 있어야한다는 합의에 도달했다고 가정하면 이전에는 작동하지 않았던 일부 사례를 허용 할 수 있습니다.

let x: Result<usize, E> = try { 3 }; // Ok
let x: Result<usize, E> = try { Ok(3) }; // Also Ok for backwards compat
let x: Result<Result<usize, E1>, E2> = try { Ok(3) }; // Ok(Ok(3))
let x: Result<Result<usize, E1>, E2> = try { Ok(Ok(3)) }; // Ok(Ok(3))

문제는 이것이 이전에 없었던 무언가를 모호하게 만들 수 있는지 여부입니다. 예를 들면 :

let x = try { Err(3) }; // If x: Result<Result<T1, usize>, usize>, then it is not clear if user meant Ok(Err(3)) or Err(3)...

그래도 Ok-wrapping이 이미이 문제를 해결해야할까요?

어쨌든 내 직감은 그런 이상한 사건이 그렇게 자주 나오지 않기 때문에 그다지 중요하지 않을 수도 있다는 것입니다.

반환 된 유형이 Result 또는 Option 경우를 제외하고 Ok-wrapping을 사용하는 것은 어떻습니까? 대부분의 경우 더 간단한 코드를 허용하지만 필요한 경우 정확한 값을 지정할 수 있습니다.

// Ok-wrapped
let v: Result<i32, _> = try { 1 };

// not Ok-wrapped since the returned type is Result
let v: Result<i32, _> = try { Ok(1) };

// not Ok-wrapped since the returned type is Result
let v: Result<i32, _> = try { Err("error") };

// Ok-wrapped
let v: Option<i32> = try { 1 };

// not Ok-wrapped since the returned type is Option
let v: Option<i32> = try { Some(1) };

// not Ok-wrapped since the returned type is Option
let v: Option<i32> = try { None };

Ok -coercion 또는 어떤 종류의 구문 종속 Ok -wrapping (안정화를 지원하고 나중에 도입해야하는 작업)을 추가하는 것은 가독성에 매우 좋지 않습니다. i.rl.o (일반적으로 구현 된 간단한 Ok -wrapping을 오해하는 사람들에 의해)에 대해 여러 번 반대하는 주장이 광범위하게 제기되었습니다.

나는 개인적으로 구현 된대로 Ok -wrapping을 강력히 선호하지만, 랩핑이 어려운 상황을 이해하게 만드는 어떤 형태의 강압이나 구문 의존성에 반대 할 것입니다. Ok(...) 은 (는) 강압적인지 아닌지를 알아 내야하는 모든 곳에서 발생합니다.

let x = try { Err(3) }; // If x: Result<Result<T1, usize>, usize>, then it is not clear if user meant Ok(Err(3)) or Err(3)...

그래도 Ok-wrapping이 이미이 문제를 해결해야할까요?

아니, 그것은 분명 Ok(Err(3)) , Ok -wrapping은 구문이나 유형에 독립적이며, 블록의 출력이 Try::Ok 변형에있는 모든 것을 래핑합니다.

@ mark-im 안정화 후 합리적으로 이동할 수 있다고 생각하지 않습니다. 내가 Ok-wrapping이라고 생각하는 것만 큼 나쁘지만, 당신이 그것을 원하는지 아닌지 추측하려고 시도하는 일관성없는 Ok-wrapping은 더 나쁠 것입니다.

내 코드베이스에서 많은 선택적 값을 다루고 있으므로 오래 전에 매크로와 같은 자체 try 블록을 도입했습니다. 그리고 제가 소개 할 때 Ok-wrapping이 있거나없는 다양한 변형이 있었는데 Ok-wrapping 버전은 훨씬 더 인체 공학적인 것으로 판명되어 제가 사용하게 된 유일한 매크로입니다.

작업해야 할 선택적 값이 많고 대부분 숫자이므로 다음과 같은 상황이 많습니다.

let c = try { 2 * a? + b? };

Ok-wrapping이 없으면 실제 try 블록을 사용하는 것보다 내 자신의 매크로에 머무를 수있을 정도로 인체 공학적이지 않습니다.

이 추적 문제의 유서 깊은 역사, ? 연산자와의 원래의 유감스러운 충돌 및 Ok -wrapping 문제에 대한 장애물을 감안할 때이 문제를 완전히 종료하고 try 보내는 것이 좋습니다.

Ok-wrapping이 없으면 인체 공학적

그것이 도입 할 정확히 비인간 공학적 요소에 대해 자세히 설명해 주시겠습니까?

Ok-wrapping이 없으면 예제는 다음과 같습니다.

let c = try { Ok(2 * a? + b?) };

제 생각에는 꽤 좋습니다.

내 말은, 이런 작은 예제로는 과잉처럼 보일 수 있지만, 더 많은 코드가 try 블록이 덜 미치는 영향이 포함 Ok(...) 원인 래퍼.

@CreepySkeleton 의 의견에 try 블록이이를 수행하지 않는 경우 Ok -wrapping을 에뮬레이트하는 매크로를 만드는 것이 매우 쉽습니다 (그리고 누군가는 이 작은 매크로의 표준 상자), 그 반대는 그렇지 않습니다.

Try 특성이 불안정한 동안에는 해당 매크로를 사용할 수 없습니다.

왜? 어쨌든 그것이 안정되면 (가설 적으로 멀지 않은 미래에) 매우 가능할 것입니다.

@ Nemo157 try 블록도 현재 야간에만 있으며, Try 제거하기로 결정한 드문 경우에 안정화되지 않을 가능성이 높습니다. 이는 Try 전에 안정화되지 않을 가능성이 있음을 의미합니다. 따라서 매크로가 불가능하다고 말하는 것은 의미가 없습니다.

@KrishnaSannasi 왜 Try 이 찢어 질 수 있는지 궁금합니다.

@ mark-im 그럴 것이라고 생각하지 않습니다. 나는 단지 Try 가 블록을 시도하기 위해 야간에 wrt에있는 것에 대해 걱정하는 것이 현실적인 문제가 아닌 이유를 설명하고 있습니다. 안정에서 Try 를 기대하고 있습니다.

? 가 이미 안정화되었고 try 블록은 ? 와 같은 방식으로 Result 및 Option 를 모두 포함하는 명확한 디자인을 가지고 있습니다 ? 않습니다, Try 안정화에 대한 안정화를 차단할 이유가 없습니다. 나는 그것을 면밀히 주시하지는 않았지만 try 블록보다 Try 의 디자인에 대한 합의가 훨씬 적어 try 볼 수있었습니다. Try 트레이 트 ( ? ) 전에 몇 년 동안 안정화됩니다. 그리고 경우에도 Try 나는 차단해야 할 이유 볼 특성 포기 try 블록은 단지 작업으로 안정되고 Result 및 Option 와 같은 ? 그러면

(_why_의 경우 안정화 된 try 블록과 불안정한 Try 특성이 주어지면 매크로를 작성할 수 없습니다. 매크로는 try { Try::from_ok($expr) } 확장됩니다. 유형별 매크로를 만들 수 있습니다. Result 및 Option 이지만 "[...] 에뮬레이션하기 매우 쉬운"점을 충족하지 못하는 IMO).

을 감안할 때 ? 특수 맡았다 안정에도 이미 Try 특성 안정적으로 사용할 수 없습니다, 내가 볼 수없는 이유는 Try 것을 시도 블록 인 차단할 수 불안정 왜냐하면 Try 특성이 제거 된 경우에도 인체 공학없이 안정된 상태에서 ? 를 지원하는 Option 및 Result가 있기 때문입니다.

try catch semantic에 대한 다음 개념을 제안합니다.

다음 코드를 고려하십시오.

union SomeFunctionMultipleError {
    err0: Error1,
    err1: Error2,
}

struct SomeFunctionFnError {
    index: u32,
    errors: SomeFunctionMultipleError,
}

fn some_function() -> Result<i32, SomeFunctionFnError> {
    if 0 == 0 {
        Ok(2)
    } else {
        Err(SomeFunctionFnError{ index: 0, errors: SomeFunctionMultipleError {err1: Error2 {id0: 0, id1: 0, id3: 0}}})
    }
}

union OtherFunctionMultipleError {
    err0: Error1,
    err1: Error2,
    err2: Error3,
}

struct OtherFunctionFnError {
    id: u32,
    errors: OtherFunctionMultipleError,
}

fn other_function() -> Result<i32, OtherFunctionFnError> {
    if 0 == 0 {
        Ok(2)
    } else {
        Err(OtherFunctionFnError {id: 0, errors: OtherFunctionMultipleError {err0: Error1 {id0: 0, id1: 0}}})
    }
}

이것은 Rust의 Zero-Overhead 예외에 의해 생성 될 수있는 코드입니다.

fn some_function() -> i32 throws Error1, Error2 {
    if 0 == 0 {
        2
    } else {
        Error2 {id0: 0, id1: 0, id3: 0}.throw
    }
}

fn other_function() -> i32 throws Error1, Error2, Error3 {
    if 0 == 0 {
        2
    } else {
        Error1{id0: 0, id1: 0}.throw
    }
}

또는 이러한 오류조차도 컴파일러에 의해 암시 적으로 추론 될 수 있습니다.

fn some_function(i: i32) -> i32 throws { // Implicitly throws Error1, Error2
    if i == 0 {
        2
    } else if i == 1 {
        Error1 {id0: 0, id1: 0, id3: 0}.throw
    } else {
        Error2 {id0: 0, id1: 0, id3: 0}.throw
    }
}

fn other_function(i: i32) -> i32 throws { // Implicitly throws Error1
    if i == 0 {
        2
    } else {
        Error1{id0: 0, id1: 0}.throw
    }
}

이것은 다른 구문 설탕! 행동은 같습니다 !!

안녕하세요,

위에있는 제로 오버 헤드 예외에 대한 제 제안을 보는 사람이 있습니까?

@redradist try 블록의 주요 포인트 중 하나는 모든 블록에 대해 함수를 만들 필요없이 함수 내부에서 사용할 수 있다는 것입니다. 당신의 제안은 내가 보는 한 여기에서 완전히 관련이 없습니다.

바로 오늘 저는 try 블록이 필요하다고 느꼈습니다. ? 작업이 많은 큰 기능이 있습니다. 오류에 컨텍스트를 추가하고 싶었지만 ? 마다 그렇게하려면 엄청난 양의 상용구가 필요했습니다. try 오류를 포착하고 컨텍스트를 한곳에 추가하면이를 방지 할 수 있습니다.

Btw. 이 경우 내부 함수로 작업을 래핑하는 것은 어려웠을 것입니다. 컨텍스트에는 명확한 수명이 없기 때문에 여러 함수로 나누면 NLL이 깨집니다.

현재 구현에서 try 블록은 표현식이 아니라는 점을 언급하고 싶습니다. 이것이 감독이라고 생각하십시오.

현재 구현에서 try 블록은 표현식이 아니라는 점을 언급하고 싶습니다. 이것이 감독이라고 생각하십시오.

작동하지 않는 코드를 게시 할 수 있습니까? 여기 표현식 컨텍스트에서 사용할 수 있습니다. ( Rust Playground )

#![feature(try_blocks)]

fn main() {
    let s: Result<(), ()> = try { () };
}

물론 입니다 .

그리고 이것은 try 블록에 대한 유형 추론이 아직 완료되지 않았 음을 보여주는 또 다른 것 입니다. if let 블록에서는 유형 지정이 지원되지 않기 때문에 특히 짜증이납니다.

@ Nokel81 이전 예제의 문제는 if let $pat = $expr 표현식이 정규 표현식 컨텍스트가 아니라 특수한 "대괄호 표현식 없음"컨텍스트라는 것입니다. 이것이 struct 표현식과 어떻게 작동하는지에 대한 예는 struct 표현식 이 있다는 것이 구문 적으로 명확한 이 예제 와 그렇지 않은 try 가 표현식이 아니라는 것이 아니라 오류가 잘못되었습니다. " try 표현식은 여기에서 허용되지 않습니다. 괄호로 묶어보십시오"(그리고 불필요한 괄호에 대한 잘못된 경고가 표시되지 않음).

후자의 예는 실제로 유형 추론에 대해 모호합니다. 이 경우 e 의 유형은 _: From<usize> 이며 구체적인 유형을 제공하기에 충분한 정보가 아닙니다. 유형 추론이 성공할 수 있도록 구체적인 유형 을 try 에만 해당되는 문제가 아닙니다. 이것이 Rust에서 타입 추론이 작동하는 방식입니다.

이제 즉시 Ok 로 일치시키고 Err case를 삭제하려고 하면 문제를 해결하는 실제 있습니다 .

아 깊이 설명 해주셔서 감사합니다. 왜 나중에 유형 추론이 모호한 지 혼란 스럽습니다. 식의 유형이 Result<isize, usize> 아닌 이유는 무엇입니까?

? 연산자는 From 트레이 트를 사용하여 서로 다른 오류 유형간에 유형 변환을 수행 할 수 있습니다. 대략 다음과 같은 rust 코드로 확장됩니다 ( Try 트레이 트 무시) :

match expr {
    Ok(v) => v,
    Err(e) => return From::from(e),
}

From 호출은 최종 반환 된 식의 유형을 사용하여 수행 할 오류 유형 변환을 결정하며, 기본적으로 전달 된 값의 유형으로 자동 설정되지 않습니다.

이 문제가 이미 해결 된 경우 사과하지만 다음과 같은 것이 이상하게 보입니다.

#![feature(try_blocks)]

fn main() -> Result<(), ()> {
    let result = try { // no type annotation
        Err(())?;
    };
    result.map_err(|err| err)
}

다음으로 컴파일하지 못했습니다.

error[E0282]: type annotations needed

그러나:

#![feature(try_blocks)]

fn main() -> Result<(), ()> {
    let result : Result<_, _> = try { // partial type annotation
        Err(())?;
    };
    result.map_err(|err| err)
}

괜찮다.

Result 의 타입 인자를 추론 할 수 없어서 문제가된다면 이해할 수 있겠지만, 위와 같이 그 결과는 아니고 rustc는 추론을 할 수 있습니다. try 표현식은 일종의 Result 이며, core::ops::Try::into_result 에서 추론 할 수 있어야합니다.

생각?

@nwsharp 는 try / ? 이 Try 유형보다 일반적이기 때문입니다. impl Try<Ok=_, Error=()> 인 다른 유형이있는 경우 try 블록은 Result 뿐만 아니라 해당 유형으로 평가 될 수 있습니다. Desugared, 귀하의 예는 대략

#![feature(try_trait, label_break_value)]

use std::ops::Try;

fn main() -> Result<(), ()> {
    let result /*: Result<_, _>*/ = 'block: {
        match Try::into_result(Err(())) {
            Ok(ok) => Try::from_ok(ok),
            Err(err) => {
                break 'block Try::from_error(From::from(err));
            }
        }
    };
    result.map_err(|err| err)
}

@ CAD97 설명해 주셔서 감사합니다.

즉, try 가 다른 Try impls간에 일종의 변환을 효과적으로 유발할 수있을 것이라고는 생각하지 못했습니다.

into_result , from_ok 및 from_error 대해 동일한 Try impl이 선택된 경우 탈 수술을 기대 합니다.

제 생각에는 유형 추론을 수행 할 수없는 인체 공학적 손실 (특히 대체 impl Try 도 존재하지 않는다는 점을 고려)이이 변환을 허용하는 이점보다 크지 않습니다.

모호함을 제거하여 추론을 허용 하고 다음과 같은 방법을 통해 전환에 대한 옵트 인 기능을 유지할 수 있습니다.

try { ... }.into()

해당하는 담요 impl :

impl<T: Try, E: Into<T::Err>> From<Result<T::Ok, E>> for T {
    fn from(result: Result<T::Ok, E>) -> Self {
        match result {
            Ok(ok) => T::from_ok(ok),
            Err(err) => T::from_err(err.into()),
        }
    }
}

(솔직히 내가 여기에 오류 유형의 자동 변환을 의심 개인적 않습니다하지만 차종에 관계없이 가진 의미한다고 가정한다.이 원했던 경우, 사용자해야 .map_err() 온 Result .)

일반적으로이 탈당은 "너무 영리하다"고 생각합니다. 너무 많이 숨기고 현재의 의미는 사람들을 혼란스럽게 할 수 있습니다. (특히 현재 구현에서 직접 지원하지 않는 유형 주석을 요청한다는 점을 고려하세요!)

또는 담요 impl로 더 나아가는 것 같습니다.

impl <T: Try, U: Try> From<U> for T 
    where U::Ok : Into<T::Ok>, U::Err : Into<T::Err>
{
    fn from(other: U) -> Self {
        match other.into_result() {
            Ok(ok) => Self::from_ok(ok.into()),
            Err(err) => Self::from_err(err.into()),
        }
    }
}

또는 무엇이든...

즉, try가 다른 Try impls간에 일종의 변환을 효과적으로 유발할 수있을 것이라고는 생각하지 못했습니다.

into_result , from_ok 및 from_error 대해 동일한 Try impl이 선택된 경우 탈 수술을 기대합니다.

제 생각에는 유형 추론을 수행 할 수없는 인체 공학적 손실 (특히 대체 impl Try 도 존재하지 않는다는 점을 고려)이이 변환을 허용하는 이점보다 크지 않습니다.

Option<T> , Result<T, E> , Poll<Result<T, E>> 및 Poll<Option<Result<T, E>> 네 가지 안정적인 Try 유형이 있습니다.

NoneError 은 (는) 불안정하므로 Option<T> 은 (는) Option<T> 멈춰 있지만 NoneError 는 불안정합니다. (문서는 명시 적으로 From<NoneError> 를 "오류 유형에 대해 option? 활성화"로 명시합니다.)

그러나 Poll impls는 오류 유형을 E 합니다. 이 때문에,의 "모핑 입력" Try 안정, 당신이 할 수 있기 때문에 ? Poll<Result<T, E>> A의 -> Result<_, E> 얻을 수있는 Poll<T> 및 E 케이스를 조기에 반환합니다.

사실, 이것은 "귀여운"작은 도우미 에게 힘을줍니다.

fn lift_err<T, E>(x: Poll<Result<T, E>>) -> Result<Poll<T>, E> { Ok(x?) }

@ CAD97 유머러스 해 주셔서 감사합니다. 이것은 초보자에게 가르치기 까다로운 일이며 오류 메시지 측면에서 상당한 사랑이 필요합니다.

여기서 원하는 impl Try 의 사양이 직관적이지 않은 동작을 보장 할 수 있다고 생각 했습니까?

예를 들어, try<T> { ... } 약간의 자전거 흘림. 아니면 그와 함께 할 일이 또 있습니까?

여기에 약간 더 많은 색상을 추가하려면 Result 묶음에 try { } 가 "단지" Result 생성하지 않는다는 사실은 예상치 못한 일 이며 나를 슬프게합니다. . 이유 는 이해하지만 마음에 들지 않습니다.

예, "일반화 된 유형 지정"(검색 할 용어가 있음) 및 try 의 조합에 대한 논의가있었습니다. 마지막으로 들었을 때 try: Result<_, _> { .. } 는 결국 작동 할 계획이었습니다.

하지만 동의합니다 : try 블록은 출력 유형이 지정되었는지 확인하기위한 몇 가지 대상 진단을받을 자격이 있습니다.

Ok -wrapping 문제에 대한 언어 팀의 합의를 해결하기 위해 특정 좁은 질문에 대해서는 이 별도의 문제 를 참조하십시오.

댓글을 달기 전에 해당 스레드의 시작 댓글을 읽어 주시기 바랍니다. 특히 스레드는 해당 질문에 대한 것이며 try 또는 ? 또는 Try 와 관련된 다른 문제가 아닙니다.

try 블록이 필요한 이유를 모르겠습니다. 이 구문

fn main() -> Result<(), ()> {
    try {
        if foo() {
            Err(())?
        }
        ()
    }
}

다음으로 대체 할 수 있습니다.

fn main() -> Result<(), ()> {
    Ok({
        if foo() {
            Err(())?
        }
        ()
    })
}

둘 다 동일한 수의 문자를 사용하지만 두 번째 문자는 이미 안정적입니다.

결과를 변수에 할당 할 때 결과를 반환하기 위해 도우미 함수를 만들어야 함을 나타낼 수 있습니다. 가능하지 않은 경우 대신 클로저를 사용할 수 있습니다.

@dylni try 블록은 함수의 전체 본문을 포함하지 않을 때 특히 유용합니다. 오류시 ? 연산자는 함수에서 반환하지 않고 흐름 제어를 가장 안쪽의 try 블록 끝으로 이동합니다.

```녹
fn main () / * 여기에 결과 없음 * / {
let result = try {
foo () ?. bar () ?. baz ()?
};
경기 결과 {
//…
}
}

@SimonSapin 그렇게 자주

fn main() /* no result here */ {
    let result  = foo()
        .and_then(|x| x.bar())
        .and_then(|x| x.baz());
    match result {
        // …
    }
}

더 장황하지만 더 간단한 솔루션은 메서드 클로저 구문이 될 것이라고 생각합니다.

fn main() /* no result here */ {
    let result  = foo()
        .and_then(::bar)
        .and_then(::baz);
    match result {
        // …
    }
}

유형은 try 대한 유형 주석이 필요한 and_then 올바르게 추론됩니다. 나는 간결한 구문이 가독성에 해를 끼칠 가치가 있다고 생각하지 않을 정도로 드물게 발생했습니다.

허용 된 RFC에는 몇 가지 추론이 있습니다. https://rust-lang.github.io/rfcs/0243-trait-based-exception-handling.html

어쨌든 and_then 와 같은 연결 메서드보다 ? (및 .await ) 연산자를 사용하는 제어 흐름에 대한 언어 구조를 선호하는 인수는 이미 광범위하게 논의되었습니다.

어쨌든 and_then 와 같은 연결 메서드보다 ? (및 .await ) 연산자를 사용하는 제어 흐름에 대한 언어 구조를 선호하는 인수는 이미 광범위하게 논의되었습니다.

@SimonSapin 감사합니다. 이것과 RFC를 다시 읽음으로써 이것이 유용 할 수 있다고 확신했습니다.

오류에 컨텍스트를 쉽게 추가하기 위해 try 블록을 사용할 수 있다고 생각했지만 지금까지는 운이 없었습니다.

잘 작동하는 작은 함수를 작성했습니다. File::open()? 는 std::io::Error 실패하고 다음 줄은 anyhow::Error 실패합니다. 유형이 다르지만 컴파일러는 둘 다 Result<_, anyhow::Error> 로 변환하는 방법을 알아냅니다.

fn tls_add_cert(config: &ClientConfig, path: impl AsRef<Path>) -> Result<(usize, usize), anyhow::Error> {
    let path = path.as_ref();
    let mut file = BufReader::new(File::open(path)?);
    Ok(config.root_store.add_pem_file(&mut file)
        .map_err(|_| anyhow!("Bad PEM file"))?)
}

오류 컨텍스트를 추가하고 싶었으므로 try-block을 사용하려고 시도했지만 with_context() :

fn tls_add_cert(config: &ClientConfig, path: impl AsRef<Path>) -> anyhow::Result<(usize, usize)> {
    let path = path.as_ref();
    try {
        let mut file = BufReader::new(File::open(path)?);
        Ok(config.root_store.add_pem_file(&mut file)
            .map_err(|_| anyhow!("Bad PEM file"))?)
    }
    .with_context(|| format!("Error adding certificate {}", path.display()))
}

그러나 이제 유형 추론이 실패합니다.

error[E0282]: type annotations needed
  --> src/net.rs:29:5
   |
29 | /     try {
30 | |         let mut file = BufReader::new(File::open(path)?);
31 | |         Ok(config.root_store.add_pem_file(&mut file)
32 | |             .map_err(|_| anyhow!("Bad PEM file"))?)
33 | |     }
   | |_____^ cannot infer type
   |
   = note: type must be known at this point
   ```

I don't understand why a type annotation is needed here but not in the first case. Nor do I see any easy way to add one, as opposed to using an [IIFE](https://en.wikipedia.org/wiki/Immediately_invoked_function_expression) which does let me add an annotation:

```rust
(|| -> Result<_, anyhow::Error> {
    let domain = DNSNameRef::try_from_ascii_str(host)?;
    let tcp = TcpStream::connect(&(host, port)).await?;

    Ok(tls.connect(domain, tcp).await?)
})()
.with_context(|| format!("Error connecting to {}:{}", host, port))

뿡 빵뀨

다시,

이는 try / ? 이 Try 유형보다 일반적이기 때문입니다. [ impl Try<Ok=_, Error=anyhow::Error> ] 인 다른 유형이있는 경우 try 블록은 Result 뿐만 아니라 해당 유형으로 평가 될 수 있습니다.

(또한 try 블록 (# 70941)에서 후행 표현식을 Ok 할 필요가 없습니다.)

이것이 계속해서 나타난다는 것은

• 안정화하기 전에 try 는 유형 지정 ( try: Result<_,_> { 또는 기타)을 지원하거나이 문제를 완화해야합니다.
• 이것은 try 블록의 유형 추론이 실패 할 때를위한 표적 진단이 확실히 필요합니다.
• 달리 제한되지 않은 경우 try 유형을 Result<_,_> 대체하는 것을 강력하게 고려해야합니다. 예, 어렵고 지정되지 않았으며 잠재적으로 문제가있을 수 있지만 $12: Try<Ok=$5, Error=$8> 가 충분히 구체적이지 않기 때문에 유형 주석이 필요한 try 블록의 80 % 경우를 _ 해결합니다.

또한, # 70941이 "예, 우리는 (일부 형태의) ' Try::from_ok 래핑'을 원합니다" "로 해결하는 것처럼 보이며, try 의 꼬리 표현이있을 때 _also_ 표적 진단을 원할 것입니다 x 가 작동 할 때 Ok(x) 반환합니다.

시도에 대한 올바른 행동은

• try: Result<_, _> { .. } , try as Result<> 등과 같은 수동 지정을 허용하도록 구문을 확장합니다 ( try: Result 가 아마도 괜찮다고 생각합니까? 선호하는 구문 인 것 같습니다)
• 컨텍스트에서 오는 "예상 유형"을 검토하십시오. 존재하는 경우 try 의 결과 유형으로 선호하십시오.
• 그렇지 않으면 기본값은 Result<_, _> . 이것은 i32 와 같은 유형 추론 폴 백이 아니며 더 일찍 발생하지만 try { }.with_context(...) 컴파일과 같은 작업을 의미합니다.

그러나 적어도 오류 유형이 지정되지 않은 한 ? 및 into 강제 변환에서 오류가 발생할 수 있다는 점이 우려됩니다. 특히 try 블록의 결과를 ? 위치에 작성하는 경우 다음과 같습니다.

#![feature(try_blocks)]

use std::error::Error;
fn foo() -> Result<(), Box<dyn Error>> {
    let x: Result<_, _> = try {
        std::fs::File::open("foo")?;
    };

    x?;

    Ok(())
}

fn main() { 
}

"into"강제가 트리거되어야하는 ? 대해 명확하지 않기 때문에 여전히 오류 ( playground )가 발생합니다.

여기에서 가장 좋은 해결책이 무엇인지 잘 모르겠지만 아마도 저를 긴장하게 만들 유형 추론 폴 백과 관련이있을 것입니다.

나를 긴장하게 만드는 유형 추론 폴 백이 포함되어있을 것입니다.

가장 간단한 방법 : 주어진 Try 블록에서 ? 의 모든 사용에 동일한 Try::Error 유형이 포함 된 경우 포함하는 try 블록에 해당 오류 유형을 사용합니다 ( 그렇지 않으면 바운드).

"(달리 묶이지 않는 한)"는 물론 미묘한 무서운 부분입니다.

이 게시물에 너무 비 구조적이지 않기를 바랍니다. 그러나 @nikomatsakis 예제를 ? 가 강제 변환을 수행하지 않고 try 블록 결과의 자동 래핑이없는 병렬 세계의 예제와 대조하고 싶었습니다.

use std::error::Error;
fn foo() -> Result<(), Box<dyn Error>> {
    let x = try {
        std::fs::File::open("foo").err_convert()?;
        Ok(())
    };

    x?;

    Ok(())
}

이 세상에서:

• try 범위와 fn 자체가 값없이 성공한다는 것을 쉽게 알 수 있습니다. Result 를 생성하려고 시도하지 않고도 쉽게 볼 수 있습니다.
• 오류 변환이 발생하는 곳은 분명합니다.
• 오류 변환을 x? 식으로 이동하여 try 범위를 std::fs::File 작업에 맞게 지정할 수 있습니다.
• 모든 유형 힌트는 유형 서명에서 유창하게 연결됩니다. 기계와 인간 모두를위한 것입니다.
• 사용자의 유형 힌트는 실제로 오류를 다른 독립적 인 오류로 접 으려는 경우에만 필요합니다.

나는 그 평행 우주에서 매우 행복 할 것입니다.

나는 당신이 그 의견을 쓴주의 길을 감사 드리며, 난 두려워 @phaylon 오히려 unconstructive입니다. 오류 변환은 ? 일부이며 변경되지 않을 것입니다. 그런 점에서 ok-wrapping은 기본적으로이 토론의 나머지 부분과 직교합니다.

try 함수 (return 및 throw 유형 포함)를 고려할 경우 try 블록을 유사한 것으로 지정하는 구문도 고려할 가치가 있습니다.

예

try fn foo() -> u32 throw String {
  let result = try: u32 throw String {
    123
  };
  result?
}

이것이 논의 되었다면 죄송하지만 사용의 장점은 무엇입니까

try fn foo() -> u32 throw String { ... }

또는 이와 반대로

fn foo() -> Result<u32, String> { ... }

?
중복 구문처럼 보입니다.

@gorilskij 내가 이해했듯이 주된 이점은 Ok -wrapping 을 얻는 것입니다. 그렇지 않으면 다음과 같이 작성해야합니다.

fn foo() -> Result<u32, String> {
    try {
        // function body
    }
}

어떤 사람들은 예외 용어가 관련이 있다고 생각하기 때문에 throws 을 선호합니다.

개인적으로 예외의 출현에서 최대한 멀리 머물고 싶습니다.

이것은 try fn 를 논의 할 스레드가 아니므로이 탄젠트를 더 이상 다루지 마십시오. 이 스레드는 try 블록의 허용 된 기능을위한 것이며, 잠재적 (그리고 아직 RFCd가 아닌) 기능 try fn 아닙니다.

방금 ? 대한 원래 RFC가 Into 가 아닌 From Into 사용하여 제안되었음을 확인했습니다. 다음과 같이 설명합니다.

현재 RFC는이 목적을 위해 std::convert::Into 특성을 사용합니다 ( From 에서 포워딩하는 포괄적 인 impl이 있음).

정확한 upcasting 방법은 해결되지 않은 질문 으로 남겨 둡니다. Into 는 From 의 지침에 따라 (아마도) 선호되었습니다.

제네릭 함수에 특성 경계를 지정할 때 From 사용보다 Into 사용을 선호합니다. 이렇게하면 Into 를 직접 구현하는 유형도 인수로 사용할 수 있습니다.

그러나 Try 트레이 트 RFC 에서 Into 는 더 이상 언급되지 않으며 대신 From 를 사용하여 변환이 수행됩니다. 이것은 ? 에서도 코드가 현재 사용하는 것입니다.
https://github.com/rust-lang/rust/blob/b613c989594f1cbf0d4af1a7a153786cca7792c8/src/librustc_ast_lowering/expr.rs#L1232

Into 에서 From 가는 포괄적 인 구현이 없기 때문에 이것은 불행한 것 같습니다. 즉, Into ( From 과는 반대로)를 구현하는 오류는 레거시 이유로 오류가 있거나 다른 필요로 인해 ? (또는 Try ). 또한 표준 라이브러리의 권장 사항을 따르는 모든 구현에서 Into in bounds를 사용할 수 없음을 의미합니다. ? . 예를 들어 표준 라이브러리는 다음과 같이 작성하도록 권장합니다.

fn with_user_err<E>(op: impl Fn() -> Result<(), E>) -> Result<(), MyError>
where E: Into<MyError>

하지만 그렇게하면 함수 본문에 ? 를 사용할 수 없습니다. 그렇게하려면 글을 써야합니다

fn with_user_err<E>(op: impl Fn() -> Result<(), E>) -> Result<(), MyError>
where MyError: From<E>

하지만 그렇게하면 From 대신 Into 를 구현하는 오류 유형을 가진 사용자는이 함수를 사용할 수 없습니다. 역 인해의 담요 IMPL에, 사실이 아니다는 것을 주 Into 에 따라 From .

지금 ? 를 고치기에는 (?) 너무 늦었을 것입니다 (아마도 _ 매우 _ 안타깝게도 – 아마도 다음 버전에서?).하지만 적어도 Try 에서 그 경로를 더 깊이 파헤 치지 않도록해야합니다.

발 desugaring 바꾸려고 @cuviper @jonhoo From 에 Into 의 # 60796을 # 38751을 확인 정확히 인해의 추론 파손 다량 초래하는 From -> Into 담요 impl로 인해 rustc가 일반적인 신원 변환 사례를 처리하기가 더 어려워졌습니다. 추론 비용을 깎을만한 가치가 없다고 결정되었습니다.

@jonhoo 당신은 또한 niko의 유익한 코멘트를 찾을 수 있습니다 :

특성 시스템에는 하드 코딩 된 제한도 있습니다. ?X: Into<ReturnType> 와 같은 목표를 해결해야하는 경우에는 해결하지 못하지만 ReturnType: From<?X> 와 같은 목표를 해결해야하는 경우 잠재적으로 성공하고 ?X 의 값을 추론합니다.

편집 : 여기서 ?X 는 알려지지 않은 추론 변수를 나타냅니다. 오늘날의 트레이 트 시스템에서 하드 코딩 된 한계는 Self 유형이 우리가 해당 옵션을 탐색하기 위해 적어도 부분적으로 유추되어야한다는 것입니다.

TL; DR은 Into 로 추론하는 것이 더 어렵고 특성 솔버가 작동하는 방식에 내재적 인 방식으로 적용된다는 것입니다.

@KrishnaSannasi @ CAD97 감사합니다, 도움이되었습니다! Into 의 구현자를 영구적으로 남겨두기 때문에 From 기반으로하는 너무 많은 안정화에 대해 여전히 걱정합니다. 여기서 추론이 결국 더 나아질 것이라는 기대가 있습니까? Into 인바운드를 선호하는 지침을 변경해야합니까? 1.41의 새로운 특성 일관성 규칙 (내 생각 엔)이 더 이상 Into 만 구현할 이유가 없으며 모든 impls 버그를 고려할 것이라고 예상하고 있습니까?

추론이 충분하다면 나중에 Into 로 변경하기 위해 순방향 호환이 가능해야합니다. From Into 의미한다는 점을 감안할 때 우리가 깨뜨릴 수있는 최악의 상황은 추론입니다.

이 ( Try 트레이 트) ? 트레이 트와 Into / From 트레이 트를 Try 를 구현하는 유형에 대한 일반 경계와 함께 사용할 수 있도록 허용합니까? Result 자체)?

즉, ? 폐쇄 또는 함수에있는 반환 예를 들어 impl Into<Result>

(저녁에 해보면 안되는 것 같나요?)

나는 이것이 안정화되는 것을보고 싶다. 이 스레드와 # 70941을 읽은 후 요약이 다음과 같이 업데이트되어야한다고 생각합니다.

1. 랩 "결과 값"으로 쳤다해야한다 "catch 블록을할지 여부를 결의는" "예로 해결"

2. 이러한 추론 문제에 대한 새로운 우려가 추가되었습니다. 아마도 다음과 같습니다.

   • [] 유형 추론 문제로 인한 인체 공학적 어려움.

ISTM은 다음과 같은 방법으로이 마지막 문제를 해결할 수 있습니다.

• 안정화 전에 try 맞춤형 유형 암호화 구문을 추가합니다.
• https://github.com/rust-lang/rfcs/pull/803 # 23416 (Type ascription)이이 문제를 해결하고 먼저 안정화되어야한다고 결정합니다.
• 일종의 자동 폴백을 추가합니다 (예 : https://github.com/rust-lang/rust/issues/31436#issuecomment -614735806에 제안 된대로 Result 에 추가)
• try 그대로 안정화하기로 결정하고 향후 개선을위한 구문 / 의미 적 공간을 남겨 둡니다.

(이러한 옵션 중 일부는 상호 배타적이지 않습니다.)

관심을 가져 주셔서 감사 드리며이 메시지가 도움이 되었기를 바랍니다.

Type ascription에는 많은 문제 (구문 및 기타)가 있으며 안정화는 말할 것도없고 곧 구현 될 것 같지 않습니다. 유형 지정 구문에서 try 블록을 차단하는 것은 적절하지 않은 것 같습니다.

Result 로의 폴백은 도움이 될 수 있지만 오류 유형의 유형 유추 문제를 해결하지 못합니다. try { expr? }? (또는 실제로 더 복잡한 등가물)에는 .into() 두 번의 호출이 있습니다. , 컴파일러가 중간 유형에 너무 많은 유연성을 제공합니다.

@ijackson 은 주도권을 가지고 현재 상태를 요약

그러나 유형 지정과 관련하여 구현 문제가 그렇게 어렵지 않은 것 같습니다. 그것은 약간의 관심을 기울이고 결승선까지 밀어 붙이는 좋은 후보가 될 수 있습니다. 구문이나 이와 유사한 것에 대해 많은 논란이 있었는지 기억이 나지 않습니다.

2020 년 8 월 5 일 수요일 02:29:06 PM -0700에 Niko Matsakis는 다음과 같이 썼습니다.

그러나 유형 지정과 관련하여 구현 문제가 그렇게 어렵지 않은 것 같습니다. 그것은 약간의 관심을 기울이고 결승선까지 밀어 붙이는 좋은 후보가 될 수 있습니다. 구문이나 이와 유사한 것에 대해 많은 논란이 있었는지 기억이 나지 않습니다.

제가 회상했듯이 주된 관심사는 유형 지정을 허용하는 것이 었습니다.
모든 곳에서 상당한 문법 변화가 발생하고 잠재적으로
하나를 제한합니다. 자세한 내용은 기억 나지 않습니다.
높인.

개인적으로 저는 인체 공학적 문제가 그렇게 나쁘지 않아서 지금이 기능을 안정화 할 가치가 없다고 생각합니다. 표현식 유형 비문이 없더라도 let 바인딩을 도입하는 것은 그렇게 추한 해결 방법이 아닙니다.

또한 try 블록은 매크로에서 유용 할 수 있습니다. 특히 @withoutboats 우수한 fehler 라이브러리가 try 에 procs 본문을 래핑 할 수 있다면 매크로 시스템의 결함으로 인한 문제가 더 적을 지 궁금합니다.

try 블록을 많이 사용하고 싶은 곳이 있습니다. 선을 넘으면 좋을 것입니다. 개인적으로 나는 라인을 통해 try 블록을 얻는 것이 필요하다면 절대적으로 100 % 희생 유형을 희생 할 것입니다. 나는 아직 "여기에 타입 어 스크립 션이 있으면 좋겠다"고 말한 상황에 처해 있지는 않지만 결국 시도 블록을 많이 시뮬레이션하기 위해 IIFE를 수행하게됩니다. 다른 장기적이고 불안정한 기능과 충돌하기 때문에 장기적이고 유용한 기능을 불안정하게 두는 것은 정말 불행한 상황입니다.

좀 더 구체적으로 말하면 Result를 반환하는 함수 내부에있을 때이 작업을 수행하지만 Option을 반환하는 작업에 대해 일종의 처리를하고 싶습니다. 즉, 일반적으로 Try가 안정적이라면 try 블록을 선호 할 것입니다. 실제로 그렇게하기 위해 주 함수에서 반환하고 싶지는 않지만 대신 체인에있는 것이 있으면 일종의 기본값을 제공합니다. 없음. 이것은 직렬화 스타일 코드에서 나에게 발생하는 경향이 있습니다.

개인적으로 나는 try 블록보다 훨씬 더 자주 타입 어 스크립 션을 원했습니다 (때로는 둘 다 원했지만). 특히, 나는 컴파일러가 내가 예상했던 것과 다른 유형을 추론하는 "유형 디버깅"으로 종종 어려움을 겪었습니다. 일반적으로 어딘가에 새로운 let 바인딩을 추가해야합니다. 이는 정말로 방해가되며 rustfmt가 실행 취소 기록을 깨뜨리는 원인이됩니다. 더욱이, 타입 어 스크립 션이 여분의 터보 피쉬를 피할 수있는 곳이 많이 있습니다.

constrast에서는 and_then 또는 다른 결합자를 사용하여 종료하지 않고 조기에 종료 할 수 있습니다. 아마도 깨끗한 aa try 블록은 아니지만 그렇게 나쁘지는 않습니다.

@steveklabnik @ mark-im Try 블록과 유형 지정은 어떤 방식으로도 충돌하지 않으며 한 기능 또는 다른 기능의 문제가 아닙니다. 단지 try 블록에 비인간적 인 유형 추론 오류가 있으며 일반화 된 유형 지정은 해당 문제를 해결하는 방법이 될 수 있지만 일반화 된 유형 지정은 단기적 기능이나 확실한 것이 아니기 때문에

이것은 우리가 일반화 된 유형 지정을 문제에 대한 해결책으로 만들지 않을 것임을 의미하지도 않습니다. 조사 할 가치가있는 한 가지 옵션은 "언젠가 일반화 된 유형 지정이 해당 문제를 해결할 것으로 예상하는 그대로 시도를 안정화"하는 것입니다. 언급 된 모든 것은 유형 지정에 대한 안정화를 차단하지 않는다는 것입니다.

@ rust-lang / lang GitHub 및 여기에서 논의되는 많은 다른 주제의 한계로 인해이 스레드에서 유형 추론 실패의 뉘앙스를 이해하기가 조금 어렵다는 것을 인정해야합니다. 추론 실패를 처리하는 방법에 대한 결정에 도달하는 것이 try 블록이 안정화되는 것을 막는 유일한 방법이기 때문에이를 논의하기 위해 회의를 갖고 누군가 추론 문제에 대해 깊이 이해하는 데 도움이 될 것이라고 생각합니다. .

저에게 한 가지 질문이 있습니다. 예를 들어,이 추론 문제는 특히 Try 에서 허용 한 변환 유연성 때문에 발생합니까? 나는 결정이 죽을 때까지 논의되었다는 것을 알고 있지만, 만약 그렇다면 이것은 Try 특성의 정의를 변경하는 것을 정당화 할 수있는 적절한 새로운 정보처럼 보입니다.

@withoutboats 나는 Try 변경 사항이 이전 버전과의 호환성 때문에 어려울 수 있음이 분명해 졌다고 생각합니다. @cramertj 는 특정 Pin impls, IIRC를 언급했습니다.