Rust: `ops::Try`에 대한 추적 문제(`try_trait` 기능)

몇 가지 자전거 보관소:

• 우리는 관련 형에게 전화를 특정 의욕을 가지고 있습니까 Error 대신 Err ? Err 라고 하면 Result 와 정렬됩니다. 다른 하나는 이미 Ok 입니다.

• 우리가 별도의 필요에 대한 특정 의욕이 있습니까 from_error 및 from_ok 대신에 단일의, 방법을 from_result 더 대칭 될 것이라고 into_result 하는 것은 다른 것입니다 특성의 절반?

( RFC 의 플레이그라운드 링크 업데이트 버전 )

@glaebhoerl

• Error 대 Err 는 https://github.com/rust-lang/rust/issues/33417#issuecomment -269108968 및 https:// 에서 TryFrom 와 관련하여 논의되었습니다 . github.com/rust-lang/rust/pull/40281; 비슷한 이유로 여기에서 이름이 선택되었다고 가정합니다.
• 나는 그것들이 서로 다른 용도를 가지고 있기 때문에 분리되어 있다고 믿고, 누군가가 실제로 Result 를 가지고 있고 T:Try 로 바꾸려고 하는 경우는 드물 것으로 예상합니다. 나는 항상 Try::from_result(Ok( 와 Try::from_result(Err( 호출하는 것보다 Try::from_ok 와 Try::from_error 를 선호하며, 매치를 작성하는 것보다 두 가지 방법을 간단하게 구현하게 되어 기쁩니다. 아마도 into_result 를 Into<Result> 가 아니라 "통과했습니까? 실패했습니까?"라고 생각하기 때문일 것입니다. 특정 유형은 중요하지 않은 구현 세부 사항으로 Result 입니다. (저는 "생산 가치 대 조기 반환에 대한 새로운 유형이 있어야 합니다.) 제안하거나 재개하고 싶지 않습니다. 그리고 문서화의 경우 from_error 가 ? 대해 말하는 것을 좋아합니다 throw )인 반면 from_ok 둘 다 동일한 방법으로 사용하는 대신 성공 랩핑(#41414)에 대해 이야기합니다.

이것이 이 댓글에 대한 올바른 포럼인지 확실하지 않습니다. 그렇지 않은 경우 리디렉션해 주세요. 스마일리:. 아마도 이것은 https://github.com/rust-lang/rfcs/pull/1859 에 있어야 했고 댓글 기간을 놓쳤습니다. 앗!

Try 트레잇을 분할하거나 into_result 메소드를 제거하는 경우가 있는지 궁금합니다. 나에게 현재 Try 는 FromResult ( from_error 및 from_ok ) 및 IntoResult ( into_result 포함)의 합과 다소 비슷합니다 from_error into_result ).

FromResult 는 ? 연산자로 매우 인체공학적인 조기 종료를 가능하게 하며, 이것이 이 기능의 킬러 사용 사례라고 생각합니다. IntoResult 는 이미 사용 사례별 메서드나 Into<Result> 로 깔끔하게 구현할 수 있다고 생각합니다. 몇 가지 유용한 예가 누락 되었습니까?

Try 특성 RFC 에 따라 expr? 는 다음과 같이 설탕을 제거할 수 있습니다.

match expr { // Removed `Try::into_result()` here.
    Ok(v) => v,
    Err(e) => return Try::from_error(From::from(e)),
}

내가 고려한 동기 부여 예는 Future 및 Option 입니다.

미래

다음과 같이 struct FutureResult: Future 대해 FromResult 자연스럽게 구현할 수 있습니다.

impl<T, E> FromResult for FutureResult {
    type Ok = T;
    type Error = E;
    fn from_error(v: Self::Error) -> Self {
        future::err(v)
    }
    fn from_ok(v: Self::Ok) -> Self {
        future::ok(v)
    }
}

Result::Err 적용될 때 impl Future 값 함수에서 반환되는 ? 대한 합리적인 구현을 가정하면 다음과 같이 작성할 수 있습니다.

fn async_stuff() -> impl Future<V, E> {
    let t = fetch_t();
    t.and_then(|t_val| {
        let u: Result<U, E> = calc(t_val);
        async_2(u?)
    })
}
fn fetch_t() -> impl Future<T, E> {}
fn calc(t: T) -> Result<U,E> {}

그것이 바로 내가 오늘 일찍 구현하려고 했던 것이고 Try 그것을 못박았습니다! 그러나 우리가 구현하려고하는 경우 현재 Try 에 대해 Future 아마도 어떤 표준 선택이 into_result ; 패닉, 차단 또는 폴링을 한 번 하는 것이 유용할 수 있지만 이 중 어느 것도 보편적으로 유용한 것 같지 않습니다. into_result 에 Try 없으면 위와 같이 조기 종료를 구현할 수 있으며 Future 를 Result 로 변환해야 하는 경우 모든 Try ) 적절한 방법으로 변환할 수 있습니다(차단할 wait 메서드 호출, poll_once() -> Result<T,E> 호출 등).

옵션

Option 도 비슷한 경우입니다. 우리는 구현 from_ok , from_err 자연스럽게 같이 Try 특성 RFC 및 변환 할 수 Option<T> 에 Result<T, Missing> 단지와 o.ok_or(Missing) 또는 편리한 방법 ok_or_missing .

도움이 되기를 바랍니다!

나는 이 모든 일에 매우 늦었을 수도 있지만 이번 주말에 ? 에 _success_ 를 단락시키려는 경우에 대비해 다소 자연스러운 의미가 있다는 생각이 들었습니다.

fn fun() -> SearchResult<Socks> {
    search_drawer()?;
    search_wardrobe()
}

그러나 이 경우 Try 특성 메서드의 이름이 맞지 않습니다.

그러나 ? 연산자의 의미를 확장합니다.

try_fold for rayon 을 프로토타이핑할 때 Consumer::full() 메서드에 대해 Try::is_error(&self) 같은 것을 원했습니다. (Rayon은 소비자가 기본적으로 푸시 스타일 반복자이기 때문에 이것을 가지고 있지만 우리는 여전히 오류를 단락시키고 싶습니다.) 대신 Result::is_err() 호출할 수 있도록 중간 값을 Result<T::Ok, T::Err> 로 저장해야 했습니다.

거기에서 Try::from_result 가 결국 T 로 돌아가기를 원했지만 match 는 T::from_ok 및 T::from_error 매핑되었습니다. 나쁘지 _않습니다.

Try 특성은 from_ok 및 from_error 가 필요한 경우 인체 공학을 위한 from_result 방법을 제공할 수 있습니다. 혹은 그 반대로도. 주어진 예에서 나는 두 가지를 모두 제공하는 경우를 봅니다.

PR #42275가 병합되었으므로 이 문제가 해결되었습니까?

@skade 유형은 LoopState 가 일부 Iterator 내부에 대해 수행하는 것과 같이 단락 회로를 정의할 수 있습니다. 아마도 Try 가 성공이나 실패 대신 "계속 또는 중단"에 대해 이야기했다면 더 자연스러울 것입니다.

@cuviper 결국 필요한 버전 은 Ok 유형 또는 Error -in-original 유형이었습니다. 나는 destructure-and-rebuild가 충분히 일반적이고 최적화가 잘되고 특성에 대한 많은 특별한 방법이 필요하지 않기를 바랍니다.

@ErichDonGubler 이것은 추적 문제이므로 해당 코드가 안정될 때까지 해결되지 않습니다.

경험 보고서:

나는 이 특성을 실행에 옮기려고 하는 것에 약간 좌절했다. 지금 여러 번 어떤 이유로든 Result 대한 고유한 변형을 정의하고 싶지만 결국 Result 를 사용하게 될 때마다 대부분 Try 구현하기 때문에 일인지 아닌지 나는

예시:

Chalk VM용 새 솔버에서 "가닥"을 풀 때의 결과를 나타내는 열거형을 갖고 싶었습니다. 여기에는 네 가지 가능성이 있습니다.

enum StrandFail<T> {
    Success(T),
    NoSolution,
    QuantumExceeded,
    Cycle(Strand, Minimums),
}

나는 ? 이 열거형에 적용될 때 "성공"을 풀기를 원했지만 다른 모든 실패는 위쪽으로 전파했습니다. 그러나 Try 특성을 구현하려면 오류 사례만 캡슐화하는 일종의 "잔여" 유형을 정의해야 했습니다.

enum StrandFail {
    NoSolution,
    QuantumExceeded,
    Cycle(Strand, Minimums),
}

하지만 일단 이 유형이 있으면 StrandResult<T> 별칭을 만들 수도 있습니다.

type StrandResult<T> = Result<T, StrandFail>;

그리고 이것이 내가 한 일입니다.

이제 이것이 단일 열거형을 갖는 것보다 반드시 나빠 보이지는 않지만 약간 이상하게 느껴집니다. 일반적으로 예를 들어 함수에 대한 문서를 작성할 때 결과를 "ok" 및 "error"로 "그룹화"하지 않고 "같음"으로 다양한 가능성에 대해 이야기합니다. 예를 들어:

    /// Invoked when a strand represents an **answer**. This means
    /// that the strand has no subgoals left. There are two possibilities:
    ///
    /// - the strand may represent an answer we have already found; in
    ///   that case, we can return `StrandFail::NoSolution`, as this
    ///   strand led nowhere of interest.
    /// - the strand may represent a new answer, in which case it is
    ///   added to the table and `Ok` is returned.

내가 " Err(StrandFail::NoSolution) 반환합니다. 이것은 Err 내가 추가해야 하는 이 성가신 아티팩트처럼 느껴지기 때문입니다.

(반면에 현재 정의는 독자가 Try impl을 참조하지 않고 ? 의 동작이 무엇인지 알 수 있도록 도와줍니다.)

이 결과가 그리 놀라운 것은 아니라고 생각합니다. 현재 Try impl 은 Result 와 동형인 항목에 ? 를 사용하도록 강제합니다. 이 균일성은 우연이 아니지만 결과적으로 기본적으로 "단지 Result "가 아닌 것들과 함께 ? 를 사용하는 것을 성가시게 만듭니다. (그 문제는 기본적으로 NoneError 발생하는 것과 동일한 문제입니다 -- Option 의 "실패"를 나타내기 위해 유형을 인위적으로 정의해야 할 필요가 있습니다.)

나는 또한 StrandFail 경우 보통의 결과가 얻는 From::from 변환을 원하지 않습니다.

연결된 Try::Error 유형이 사용자에게 직접 노출/사용된 적이 있습니까? 아니면 ? 디슈가링의 일부로 필요합니까? 후자의 경우, 그냥 "구조적"을 정의하는 실제 문제가 표시되지 않습니다 - type Error = Option<Option<(Strand, Minimums)>> 이든 뭐든. ( enum 정의의 "실패 절반"에 해당하는 구조를 파악해야 하는 것은 좋지 않지만 전체 공개 API를 재지거해야 하는 것보다 덜 성가신 것 같습니다.)

저도 따라하지 않습니다. 내부 오류 표현이 있는 유형에 대해 Try를 성공적으로 구현했으며 Ok 및 Error 가 동일한 유형인 것이 자연스럽습니다. 여기에서 구현을 볼 수 있습니다: https://github.com/kevincox/ecl/blob/8ca7ad2bc4775c5cfc8eb9f4309b2666e5163e02/src/lib.rs#L298 -L308

실제로 이 작업을 수행하기 위한 상당히 간단한 패턴이 있는 것 같습니다.

impl std::ops::Try for Value {
    type Ok = Self;
    type Error = Self;

    fn from_ok(v: Self::Ok) -> Self { v }
    fn from_error(v: Self::Error) -> Self { v }
    fn into_result(self) -> Result<Self::Ok, Self::Error> {
        if self.is_ok() { Ok(val) } else { Err(val) }
    }
}

성공을 풀고 싶다면 다음과 같이 작동해야 합니다.

impl std::ops::Try for StrandFail<T> {
    type Ok = T;
    type Error = Self;

    fn from_ok(v: Self::Ok) -> Self { StrandFail::Success(v) }
    fn from_error(v: Self::Error) -> Self { v }
    fn into_result(self) -> Result<Self::Ok, Self::Error> {
        match self {
            StrandFail::Success(v) => Ok(v),
            other => Err(other),
        }
    }
}

구조적 유형을 정의하는 것은 가능하지만 꽤 성가신 느낌이 듭니다. Self 사용할 수 있다는 데 동의합니다. 그런 다음 StrandResult 에서 Result<_, StrandResult> 등으로 변환하기 위해 ? 를 사용할 수 있다는 것은 나에게 약간 이상하게 느껴집니다.

훌륭한 경험 보고서, @nikomatsakis! 나는 또한 Try (다른 방향에서) 불만족했습니다.

TL/DR : FoldWhile 이 말이 맞다고 생각합니다. Break -vs- Continue ? 해석에 대해 이야기하는 대신 그것은 오류 측면에서.

더 길게:

나는 ? 가 너무 편리하기 때문에 "오류"보다 "성공"에 더 가까운 것에 Err 를 계속 사용합니다.

• try_fold 를 사용하여 position (및 기타 여러 반복자 메서드) Result (내 두뇌는 find Err 것을 찾는 것 ) 대신 Break 및 Continue 변형 으로 나만의

• itertools 에서 tree_fold1 를 작성할 때 내부 함수가 항상 Err 반환 하는 이상한 None 가 Iterator::next() 의 "오류" 라는 이상한 연결 끊김이 있지만 동시에 끝까지 도달해야 하기 때문에 fold 의 "성공"입니다. 수행 할. 그리고 ? (Rust 1.12에서 컴파일해야 하므로 해당 코드에서 try! ) 를 사용하여 종료 조건을 전파하는 것이 매우 편리합니다.

따라서 다른 것이 아니라면 Try 대해 작성한 설명 이 잘못되었다고 생각하고 "성공/실패 이분법"에 대해 이야기해서는 안되며 "오류"에서 추상화해야 합니다.

내가 생각한 또 다른 것은 Try 대해 약간 미친 impls를 고려해야 한다는 것입니다. 예를 들어, Ordering: Try<Ok = (), Error = GreaterOrLess> 는 "함수 시도"와 결합되어 struct Foo<T, U> { a: T, b: U } 에 대한 cmp 를 허용할 수 있습니다.

fn cmp(&self, other: &self) -> Ordering try {
    self.a.cmp(&other.a)?;
    self.b.cmp(&other.b)?;
}

나는 그것이 좋은 종류의 미친 것인지 나쁜 종류인지 아직 모릅니다.웃음: 하지만 일단 물건이 다르면 그것들이 다르다는 것을 알 수 있기 때문에 확실히 우아함이 있습니다. 그리고 그 양쪽에 "성공"이나 "오류"를 할당하려는 시도는 잘 맞지 않는 것 같습니다.

또한 "오류 변환"이 도움이 되지 않는 또 다른 경우입니다. 나는 또한 위의 "I want ? but it's not error" 예제에서 사용한 적이 없습니다. 그리고 그것은 확실히 추론의 슬픔을 유발하는 것으로 알려져 있으므로 결과로만 제한되어야 하는 것(또는 잠재적으로 제거되어 .map_err(Into::into) 이지만 실행 불가능할 수 있음)인지 궁금합니다.

편집: 아, 그리고 "내 오류 유형에 대해 Try 를 구현하는 대신 오류에 대해 계속 결과를 사용합니다"에 대한 대답이 "좋습니다. 예상한 것입니다"인지 궁금합니다.

편집 2: 이것은 위의 https://github.com/rust-lang/rust/issues/42327#issuecomment -318923393과 다릅니다.

편집 3: Continue 변형이 https://github.com/rust-lang/rfcs/pull/1859#issuecomment -273985250에서도 제안된 것 같습니다.

내 2센트:

나는 @fluffysquirrels 의 특성을 두 특성으로 분할하는 제안을 좋아합니다. 하나는 결과로 변환하기 위한 것이고 다른 하나는 결과에서 변환하기 위한 것입니다. 그러나 나는 우리가 디슈가링의 일부로 into_result 또는 이에 상응하는 것을 유지해야 한다고 생각합니다. 그리고 이 시점에서 Option 를 Try 이후 안정화되어야 한다고 생각합니다.

나는 또한 @scottmcm 의 오류/확인이 아닌 중단/계속을 제안하는 이름을 사용하는 아이디어를 좋아합니다.

여기에 특정 코드를 넣으려면 다음과 같이 읽는 것이 좋습니다.

https://github.com/rust-lang/rust/blob/ab8b961677ac5c74762dcea955aa0ff4d7fe4915/src/libcore/iter/iterator.rs#L1738 -L1746

물론 직선 루프만큼 좋지는 않지만 "방법 시도"를 사용하면 가깝습니다.

self.try_for_each(move |x| try { 
    if predicate(&x) { return LoopState::Break(x) } 
}).break_value() 

비교를 위해 "오류 어휘" 버전이 정말 오해의 소지가 있음을 발견했습니다.

self.try_for_each(move |x| { 
    if predicate(&x) { Err(x) } 
    else { Ok(()) } 
}).err() 

NoneError에 대한 디스플레이를 구현할 수 있습니까? 실패 상자가 자동으로 From<NoneError> for failure::Error 파생하도록 허용합니다. https://github.com/rust-lang-nursery/failure/issues/61 참조
3줄 변경이 되어야 하는데 RFC 등의 과정을 잘 모르겠습니다.

@cowang4 지금은 결과와 옵션을 더 이상 혼합하지 않으려고 합니다. 유형이 불안정하여 옵션을 계속 열어 두는 것이 대부분이기 때문입니다. Try 의 디자인과 디슈가를 NoneError 가 필요하지 않은 디자인으로 바꾼다고 해도 나는 놀라지 않을 것입니다 ...

@scottmcm 알겠습니다. 너의 의도를 알 겠어. 나는 결국 라이브러리 함수가 None을 반환할 때 Err을 반환하는 패턴을 깔끔하게 만드는 방법을 원합니다. Try 이외의 다른 것을 알고 있습니까? 예시:

fn work_with_optional_types(pb: &PathBuf) -> Result<MyStruct, Error> {
    if let Some(filestem) = pb.file_stem() {
        if let Some(filestr) = filestem.to_str() {
            return Ok(MyStruct {
                filename: filestr.to_string()
            });
        }
     }
    Err(_)
}

이 실험적인 기능과 failure 상자를 찾은 후 자연스럽게 다음 사항에 끌렸습니다.

use failure::Error;
fn work_with_optional_types(pb: &PathBuf) -> Result<MyStruct, Error> {
    Ok({
        title: pb.file_stem?.to_str()?.to_string()
    })
}

이전에 언급한 것처럼 impl Display for NoneError 가 없다는 점을 제외하고는 _거의_ 작동합니다.
그러나 이것이 우리가 원하는 구문이 아닌 경우 패턴을 단순화하는 다른 함수/매크로가 있을 수 있습니다.

if option.is_none() {
    return Err(_);
}

@cowang4 Display 를 구현한 고유한 유형을 사용하는 failure::Error 대해 From<NoneError> 를 구현했다면 작동할 것이라고 생각합니다.

그러나 opt.ok_or(_)? 를 사용하는 것이 더 나은 방법일 수 있으므로 Option이 None인 경우 오류가 무엇인지 명시적으로 말할 수 있습니다. 예를 들어, to_str() 가 None을 반환하는 경우와 pb.file_stem 가 None인 경우 다른 오류가 필요할 수 있습니다.

@tmccombs 내 자신의 오류 유형을 만들려고 시도했지만 잘못했을 것입니다. 다음과 같았습니다.

#[macro_use] extern crate failure_derive;

#[derive(Fail, Debug)]
#[fail(display = "An error occurred.")]
struct SiteError;

impl From<std::option::NoneError> for SiteError {
    fn from(_err: std::option::NoneError) -> Self {
        SiteError
    }
}

fn build_piece(cur_dir: &PathBuf, piece: &PathBuf) -> Result<Piece, SiteError> {
    let title: String = piece
        .file_stem()?
        .to_str()?
        .to_string();
    Ok(Piece {
        title: title,
        url: piece
            .strip_prefix(cur_dir)?
            .to_str()
            .ok_or(err_msg("tostr"))?
            .to_string(),
    })
}

그런 다음 내 오류 유형을 사용해 보았습니다 ...

error[E0277]: the trait bound `SiteError: std::convert::From<std::path::StripPrefixError>` is not satisfied
   --> src/main.rs:195:14
    |
195 |           url: piece
    |  ______________^
196 | |             .strip_prefix(cur_dir)?
    | |___________________________________^ the trait `std::convert::From<std::path::StripPrefixError>` is not implemented for `SiteError`
    |
    = help: the following implementations were found:
              <SiteError as std::convert::From<std::option::NoneError>>
    = note: required by `std::convert::From::from`

error[E0277]: the trait bound `SiteError: std::convert::From<failure::Error>` is not satisfied
   --> src/main.rs:195:14
    |
195 |           url: piece
    |  ______________^
196 | |             .strip_prefix(cur_dir)?
197 | |             .to_str()
198 | |             .ok_or(err_msg("tostr"))?
    | |_____________________________________^ the trait `std::convert::From<failure::Error>` is not implemented for `SiteError`
    |
    = help: the following implementations were found:
              <SiteError as std::convert::From<std::option::NoneError>>
    = note: required by `std::convert::From::from`

좋아, 방금 다른 오류 유형에서 내 오류로 변환하는 방법을 알고 싶어한다는 것을 깨달았습니다. 이 오류는 일반적으로 작성할 수 있습니다.

impl<E: failure::Fail> From<E> for SiteError {
    fn from(_err: E) -> Self {
        SiteError
    }
}

아니요...

error[E0119]: conflicting implementations of trait `std::convert::From<SiteError>` for type `SiteError`:
   --> src/main.rs:183:1
    |
183 | impl<E: failure::Fail> From<E> for SiteError {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: conflicting implementation in crate `core`:
            - impl<T> std::convert::From<T> for T;

알겠습니다. std::error::Error 어떻습니까?

impl<E: std::error::Error> From<E> for SiteError {
    fn from(_err: E) -> Self {
        SiteError
    }
}

그것도 작동하지 않습니다. 부분적으로는 내 From<NoneError> 와 충돌하기 때문입니다.

error[E0119]: conflicting implementations of trait `std::convert::From<std::option::NoneError>` for type `SiteError`:
   --> src/main.rs:181:1
    |
175 | impl From<std::option::NoneError> for SiteError {
    | ----------------------------------------------- first implementation here
...
181 | impl<E: std::error::Error> From<E> for SiteError {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `SiteError`
    |
    = note: upstream crates may add new impl of trait `std::error::Error` for type `std::option::NoneError` in future versions

NoneError 이 std::error::Error 구현하지 않았다고 생각했기 때문에 이상합니다. 내 비 일반 impl From<NoneError> 주석 처리하면 다음을 얻습니다.

error[E0277]: the trait bound `std::option::NoneError: std::error::Error` is not satisfied
   --> src/main.rs:189:25
    |
189 |       let title: String = piece
    |  _________________________^
190 | |         .file_stem()?
    | |_____________________^ the trait `std::error::Error` is not implemented for `std::option::NoneError`
    |
    = note: required because of the requirements on the impl of `std::convert::From<std::option::NoneError>` for `SiteError`
    = note: required by `std::convert::From::from`

모든 From 수동으로 작성해야 합니까? 나는 실패 상자가 그것들을 이끌어 내야한다고 생각 했습니까?

아마도 option.ok_or() 고수해야 할 것입니다.

모든 From을 수동으로 작성해야 합니까? 나는 실패 상자가 그것들을 이끌어 내야한다고 생각 했습니까?

저는 실패 상자가 그렇게 하지 않는다고 생각합니다. 하지만 내가 틀릴 수 있습니다.

좋아, 그래서 나는 실패 상자를 다시 조사했고 문서와 다른 버전을 올바르게 읽고 있다면 Result 의 오류 유형으로 항상 failure::Error 를 사용하도록 설계되었습니다. 여기를 참조하십시오 . 그리고 대부분의 오류 유형에 대해 포괄적인 impl Fail 특성을 구현합니다.

impl<E: StdError + Send + Sync + 'static> Fail for E {}

https://github.com/rust-lang-nursery/failure/blob/master/failure-1.X/src/lib.rs#L218

그리고 impl From 하여 Try / ? 다른 오류(std의 오류와 같은)를 가장 중요한 failure::Error 유형으로 만들 수 있습니다.
rust impl<F: Fail> From<F> for ErrorImpl
https://github.com/rust-lang-nursery/failure/blob/d60e750fa0165e9c5779454f47a6ce5b3aa426a3/failure-1.X/src/error/error_impl.rs#L16

다만, 이 녹 문제와 관련된 오류 NoneError 는 실험적이므로 Display 특성을 구현하지 않기 때문에 아직 자동으로 변환할 수 없습니다. 그리고 Option 와 Result 사이의 경계가 흐려지기 때문에 원하지 않습니다. 결국에는 모두 재작업되고 정리될 것이지만 지금은 내가 배운 설탕 제거 기술을 고수할 것입니다.

도와주신 모든 분들께 감사드립니다. 천천히 Rust를 배우고 있습니다! :웃다:

나는 내가 배운 무설탕 기술을 고수할 것입니다.

:+1: 솔직히 말해서 .ok_or(...)? 는 계속 갈 길이라고 생각합니다(또는 .ok_or_else(|| ...)? , 물론). NoneError _had_ Display impl 경우에도 뭐라고 할까요? "뭔가 없었어"? 큰 오류는 아니지만...

구체적인 제안에 한걸음 더 다가가려 하다니...

TrySuccess 대안이 마음에 들기 시작했습니다. 흥미롭게도 저를 포함한 _아무도_는 원래 그것을 좋아했다고 생각합니다. RFC의 최종 버전에도 없습니다. 그러나 다행히도 그것은 역사에서 살아 : https://github.com/rust-lang/rfcs/blob/f89568b1fe5db4d01c4668e0d334d4a5abb023d8/text/0000-try-trait.md#using -an 관련-유형에 대한 - 더 - 성공 -값

가장 큰 반대는 연관된 유형( trait TrySuccess { type Success; } )에 대한 전체 핵심 특성이 과도하다는 합리적인 불만이었습니다. 그러나 catch try (https://github.com/rust-lang/rust/issues/41414#issuecomment-373985777) ok-wrapping(RFC에서와 같이)을 수행할 수 있습니다. , 갑자기 직접적이고 중요한 용도가 있습니다. 이것이 바로 래핑을 제어하는 ​​특성입니다. " ? 는 항상 동일한 유형을 생성해야 함"이라는 목표와 함께 일반적으로 원한다고 생각하는 목표와 함께 특성이 무게를 더 잘 유지하는 것 같습니다. 스트로맨:

trait TryContinue {
    type Continue;
    fn from_continue(_: Self::Continue) -> Self;
}

? 연산자에서 반환되는 관련 유형도 분명히 존재해야 하는 유형입니다. 이는 Niko가 분명히 말한 "일종의 '잔여' 유형을 정의해야 하는" 성가심을 치지 않는다는 것을 의미합니다. 그리고 () 것은 합리적이고 일반적이기 때문에 NoneError 와 같은 비틀림을 피합니다.

편집: 자전거 보관소의 경우 "반환"이 좋은 단어일 수 있습니다. try 메서드(일명 ok-wrapping)에서 return 가 발생하기 때문입니다. return 는 이것에 대한 모나드 연산자 이름 이기도 합니다. iiuc...

편집 2: 다른 특성/방법에 대한 내 생각은 아직 안정화되지 않았습니다. @tmccombs.

@scottmcm 그냥 명확하게, 아니면 다음 두 가지 특성을 제안합니까?

trait TryContinue {
  type Continue;
  fn from_continue(_: Self::Continue) -> Self;
}

trait Try<E>: TryContinue {
  fn try(self) -> Result<Self::Continue, E>
}

그리고 x? desuguring은 다음과 같습니다.

x.try() match {
    Ok(c) => c,
   Err(e) => throw e // throw here is just a placeholder for either returning or breaking out of a try block
}

try { ...; expr} 는 다음과 같이 설탕을 제거합니다.

{ 
    ...
    TryContinue::from_continue(expr);
}

@scottmcm 저도 ok-wrapping을 고려할 때 그 변형이 훨씬 더 매력적이라는 것을 알았습니다 =)

다음 특성으로 계속 진행하면 ? 대한 특성은 다음과 같습니다(모듈로 대규모 자전거 이동).

trait Try<Other: TryContinue = Self>: TryContinue + Sized {
    fn check(x: Other) -> ControlFlow<Other::Continue, Self>;
}

enum ControlFlow<C, B> {
    Continue(C),
    Break(B),
}

다양한 근거:

• 이 필요 TryContinue 의 유형 인수 유형에 대한 있도록 x? 표현이 항상 동일
• 동일한 유형을 검사하고 반환하는 try_fold 와 같은 간단한 경우에 type 매개변수의 기본값이 Self 이므로 T: Try 됩니다.
• 이 특성은 TryContinue 확장합니다. 리턴 유형으로 사용된 유형이 본문에 ? 를 허용하면 ok-wrapping도 지원해야 하기 때문입니다.
• 새로운 열거형은 결과와 동형이지만 위에서 논의한 바와 같이 "오류"의 관점에서 말하는 것을 피하고 결과적으로 각 변형에 대해 매우 명확한 의미를 제공한다고 생각합니다.
• ? 대한 인수는 일반 유형이므로 TryContinue 와 같이 "어떤 것에서 Self 를 생성"합니다.

try{} / ? 대한 매크로 및 Option , Result 및 Ordering 대한 impls를 포함한 전체 개념 증명 데모: https ://play.rust-lang.org/?gist=18663b73b6f35870d20fd172643a4f96&version=stable ( 1 년 전에 준 @nikomatsakis 에게 감사드립니다 🙂)

단점:

• 내가 정말 좋아하지 않는 Result impl에 여전히 팬텀 유형 매개변수가 있습니다.
  
  
  
  • 그러나 Ordering impl에 추가 LessOrGreater 유형이 필요하지 않은 것에 대한 좋은 절충안일 수 있습니다.
  
  
  • 그리고 impls의 팬텀 유형 매개변수는 어쨌든 유형보다 덜 까다롭습니다.
  
  
• 일관된 From 변환을 제공하지 않음
  
  
  
  • 그러나 StrandResult 는 어쨌든 상관하지 않기 때문에 좋을 수 있습니다 SearchResult 와 같은 항목의 경우 중단 경로가 성공 경로이기 때문에 이상할 수 있으며 결국 추론에 도움이 될 수 있습니다. 어쨌든 중첩된 ? 케이스.
  
  
• throw 구문이 무엇인지 명확하지 않습니다.
  
  
  
  • 내가 정말 좋아하는 Ok(x) => x, Err(r) => throw e.into() 로 ? 대한 설명을 잃습니다.
  
  
  • 그러나 throw; 가 None ( impl<T> Throw<()> for Option<T> 와 같은 것을 통해)을 생성하는 방법이 될 수도 있습니다. 이는 throw NoneError; 보다 훨씬 낫습니다.
  
  
  • 그리고 throw LessOrGreater::Less 는 _정말_ 어리석었을 것이기 때문에 그것을 분리하는 것은 어쨌든 좋을 수 있습니다.
  
  

편집: Ping @glaebhoerl , RFC 1859의 큰 참가자로서 이에 대한 의견을

편집 2: https://github.com/rust-lang/rfcs/pull/1859#issuecomment -287402652의 이 진술에 대해 @colin-kiegel도

나는 본질주의적 접근이 위의 목표를 희생하지 않으면서 환원주의자들의 우아함을 일부 받아들일 수 있는지 궁금합니다.

나는 그 제안이 정말 마음에 든다.

throw 구문이 무엇인지 명확하지 않습니다.

다른 언어에서 throw 키워드의 수하물을 무시하고 "throw"는 더 높은 범위까지 값을 "던지고" 있다는 점에서 일종의 의미가 있습니다. Python과 scala는 또한 오류 사례 이외의 제어 흐름에 대해 예외를 사용하므로(스칼라의 경우 일반적으로 직접 try/catch를 사용하지 않음) 성공적인 경로에 throw를 사용하는 몇 가지 선례가 있습니다.

@tmccombs

다른 언어에서 throw 키워드의 수하물을 무시하고 "throw"는 더 높은 범위까지 값을 "던지고" 있다는 점에서 일종의 의미가 있습니다.

비슷한 수하물과 함께 제공되지만 "raise"가 더 적합하다고 생각합니다.

던지다(동사): 던지는 것처럼 어떤 장소, 위치, 상태 등을 가거나 오게 하다:

상승(v): 더 높은 위치로 이동합니다. 들어 올리다; 올리다

"raise"를 ? 논리와 결합하는 방법이 있을 수 있습니다. 즉, raise가 "수집"을 의미할 수도 있습니다. Ok(v) => v, Err(e) => raise From::from(e) , 여기서 raise 는 일치하는 패턴을 모방합니다(예: Err(e) 패턴이 주어지면 ControlFlow::Break(Err(...)) 대한 문법적 마술임).

'올림'이 더 적합하다고 생각합니다.

좋은 지적

@scottmcm

throw 구문이 무엇인지 명확하지 않습니다.

from_err(value: Other) 가질 수 없는 이유가 있습니까?

업데이트: 사실 Other 의 역할에 대해 혼란스러울 수 있습니다. 이 특성을 좀 더 연구해야 합니다. =)

@nikomatsakis

from_err(value: Other) 가질 수 없는 이유가 있습니까?

글쎄, Other 는 전체 ? -able 유형(예: Result )이므로 throw Ok(4) 가 작동하는 것을 원하지 않습니다. (그리고 인위적인 오류 유형을 강제로 도입하지 않으려면 전체 분리가 필요합니다.) 예를 들어, 현재 Option-Result interop은 다음과 같을 것이라고 생각합니다.

impl<T, F, U> Try<Option<U>> for Result<T, F>
   where F: From<NoneError>
{
    fn check(x: Option<U>) -> ControlFlow<U, Self> {
        match x {
            Some(x) => ControlFlow::Continue(x),
            None => ControlFlow::Break(Err(From::from(NoneError))),
        }
    }
}

throw 대한 나의 현재 성향은 다음과 같습니다.

trait TryBreak<T> : TryContinue { from_break(_: T) -> Self }

~와 함께

throw $expr  ==>  break 'closest_catch TryBreak::from_break($expr)

• TryContinue 확장하여 ok-wrapping이 사용된 메서드의 반환 유형에도 사용할 수 있도록 합니다.
• 연결된 유형이 아니므로 원하는 경우 유형에 대해 TryBreak<TryFromIntError> 및 TryBreak<io::Error> 를 둘 다 암시할 수 있습니다.
  
  
  
  • 그리고 impl<T> TryBreak<()> for Option<T> 단지 사용하려면 throw; 의 관련 오류 유형있는 방법으로 그럴듯한 느낌 () 하지 않았다.
  
  
  • impl<T> TryBreak<!> for T 도 좋지만 아마도 일관성이 없을 것입니다.
  
  

(제외: 이러한 특성 및 메서드 이름은 끔찍합니다. 도와 주세요!)

여기서 제기된 다른 문제에 대한 내 생각은 아직 쉽게 설명할 수 있는 형식으로 정리되지 않았지만 From::from() 디슈가링과 관련된 유형 추론 문제와 관련하여(최근에 다른 곳에서도 이 문제가 논의되었는지 기억나지 않습니다. , 또는 여기에서만?):

"그런 식으로 거짓말 유형 추론 모호성"이 있다는 본능적 감각 (하스켈 경험에서)은 원래 RFC의 일부로 From 변환을 원하지 않는 이유 중 하나였습니다(주요는 아니지만). 그러나 이제 케이크에 구워졌으므로 유형 추론 프로세스에 특별한 기본 규칙을 '그냥' 추가하여 케이크를 가지고 그것을 먹으려고 할 수는 없는지 궁금합니다.

그게 내가 생각입니다 : 우리는 볼 때마다 From::from() :에 의해 삽입 된 하나의 옵션으로 ? , 우리는 정확히 두 가지 유형 중 하나를 알고 (입력 desugaring보다는 수동으로 작성을] 대 출력), 다른 하나는 모호하지만 다른 하나는 기본적으로 하나와 동일하게 설정합니다. 즉, 어떤 impl From 를 사용할지 확실하지 않은 경우 기본적으로 impl<T> From<T> for T 합니다. 이것은 기본적으로 항상 당신이 실제로 원하는 것이라고 생각합니다. 약간 임시적일 수 있지만 작동한다면 이점은 비용 IMHO의 가치가 있는 것 같습니다.

(나는 또한 생각 From 정확하게 인해로, 이미 랭 항목이었다 ? desugaring하지만, 어떤 경우에는, 그 이유로 몇 가지 특별 이미입니까? 될 것 같지 않습니다 .)

@scottmcm 의 제안에서 From::from() 는 디슈가링의 일부가 _아닌_ Try 대한 Result 있습니다.

@tmccombs 나는 그의 제안에 대한 수정안을 제안한 것이 아닙니다.

try{} RFC(https://github.com/rust-lang/rfcs/pull/2388)는 결과에 신경 쓰지 않는 try 블록에 대해 논의했습니다. 이 대안은 원할 경우 오류 유형을 완전히 무시하도록 선택할 수 있으므로 적절하게 잘 처리하는 것 같습니다.

let IgnoreErrors = try {
    error()?;
    none()?;
};

이전과 동일한 특성을 사용한 개념 증명 구현: https://play.rust-lang.org/?gist=e0f6677632e0a9941ed1a67ca9ae9c98&version=stable

나는 거기에 몇 가지 흥미로운 가능성이 있다고 생각합니다. 특히 사용자 정의 구현은 결과만 가져오고 E: Debug 바인딩하여 발생하는 모든 오류를 자동으로 기록할 수 있기 때문입니다. 아니면 버전에 대한 반환 형식으로 특별히 구성 할 수 main 와 함께 Termination "바로 작동"당신이 사용할 수 있도록하기 ? 복잡한 유형의 서명이없는 (HTTPS //github.com/rust-lang/rfcs/issues/2367).

Try 트레잇 의 기존 버전을 사용하여 https://github.com/SergioBenitez/Rocket/issues/597#issuecomment -381533108을 참조

@scottmcm 이 제안한 특성 정의는 이러한 문제를 해결합니다. 그러나 그것들은 필요 이상으로 복잡해 보입니다. 나는 그것들을 다시 구현하는 데 균열을 내고 다음을 생각해 냈습니다.

#[derive(Debug, Copy, Clone)]
enum ControlFlow<C, B> {
    Continue(C),
    Break(B),
}

// Used by `try { }` expansions.
trait FromTry: Try {
    fn from_try(value: Self::Continue) -> Self;
}

// Used by `?`.
trait Try<T = Self>: Sized {
    type Continue;
    fn check(x: T) -> ControlFlow<Self::Continue, Self>;
}

주요 변경 사항은 FromTry (이전에는 TryContinue )와 달리 Try Continue 관련 유형이 Try 특성에 있다는 것입니다. 정의를 단순화하는 것 외에도 이것은 Try 가 FromTry 와 독립적으로 구현될 수 있고 FromTry 구현이 Try 가 구현되었습니다. (참고: Try 와 FromTry 동시에 구현하려면 from_try 메서드를 Try )

이 플레이그라운드에서 Result 및 Option 뿐만 아니라 Rocket의 Outcome 에 대한 구현이 포함된 전체 플레이그라운드를 확인 하세요.

보고해 주셔서 감사합니다. @SergioBenitez! 그 구현은 RFC 1859의 원래 특성 제안의 "형식 매개 변수를 뒤집어"다른 버전과 일치 : https://github.com/rust-lang/rfcs/blob/f89568b1fe5db4d01c4668e0d334d4a5abb023d8/text/0000-try-trait.md#unresolved -질문

가장 큰 손실은 typeof(x?) 가 typeof(x) 에만 의존하는 속성입니다. 해당 속성이 없다는 것은 원본에 대한 우려 중 하나였습니다("이 라인에 따른 코드의 가독성에 대해 약간 걱정합니다" https://github.com/rust-lang/rfcs/pull/1859#issuecomment-279187967). 최종 환원주의적 제안("주어진 유형 T에 대해 ?는 정확히 한 종류의 ok/error 값을 생성할 수 있습니다" https://github.com/rust-lang/rfcs/pull/1859#issuecomment-283104310). 물론 해당 속성이 불필요하거나 너무 제한적이라는 주장도 있었지만 FCP 이전의 최종 요약에서는 여전히 이점으로 있었습니다(https://github.com/rust-lang/rfcs/pull/1859#issuecomment -295878466).

정의를 단순화하는 것 외에도 Try 가 FromTry 와 독립적으로 구현될 수 있다는 장점이 있습니다.

확실히 오늘날 from_ok Try 및 do catch 가 불안정하기 때문에 from_ok 는 덜 일반적입니다. 그리고 do catch 가 안정적이더라도 전체적으로 ? 미만으로 사용된다는 데 동의합니다(대부분의 이러한 블록에는 여러 개의 ? 포함되어 있기 때문에).

그러나 특성과 그 작업의 관점에서 "캐리어 유형에 '계속' 값을 래핑하는 것"은 ? 의 절대적으로 필수적인 부분이라고 생각합니다. 오늘날에는 Ok(...) 또는 Some(...) 대신 사용하는 특성을 거의 거치지 않지만 일반적인 사용에서는 중요합니다. 예: try_fold :

https://github.com/rust-lang/rust/blob/8728c7a726f3e8854f5a80b474d1a8bacab10304/src/libcore/iter/iterator.rs#L1478 -L1482

함수가 캐리어 유형을 반환할 경우 해당 캐리어 유형에 관심 값을 넣을 수 있는 방법이 있어야 합니다. 그리고 중요한 것은, 이것을 제공하는 것이 어려운 일이 아니라고 생각합니다. Result, Option, Outcome 등에 대한 매우 자연스러운 정의가 있습니다.

@Centril 은 이전에 "캐리어에 스칼라를 래핑하는 것"도 이론적으로 더 간단한 구성이라고 지적했습니다. 예를 들어, 하스켈은 그것을 호출 Pointed typeclass 나는 우리가 녹에서 멀리 _that_을 일반화 할 생각하지 않습니다하지만, : 수 try { 4 } ↦ vec![4] 나에게 잔인한 것 같아 .

나는 또한 async 함수가 블록 값을 미래로 래핑하기 위해 제안된 것처럼 블록 값을 오류 가능한 유형으로 래핑하는 try 함수가 있을 수 있는 미래를 상상하고 있습니다. 여기서 다시 TryContinue 가 중요한 부분입니다. throw 구문이 있는 경우 이러한 함수는 ? 도 사용하지 않을 수 있습니다.

불행히도 그 모든 것은 구체적인 것보다 더 철학적입니다. 그것이 의미가 있는지, 또는 부분에서 반대라고 생각하는지 알려주십시오 :slightly_smiling_face:

편집 : 이 버전의 초기 버전이 포함된 이메일을 받았다면 죄송합니다. 제가 댓글을 너무 일찍 눌렀네요...

가장 큰 손실은 typeof(x?)가 typeof(x)에만 의존하는 속성입니다.

아, 물론입니다. 지적해주셔서 감사합니다.

물론 해당 속성이 불필요하거나 너무 제한적이라는 주장도 있었지만 FCP 이전의 최종 요약에서는 여전히 이점으로 있었습니다(rust-lang/rfcs#1859(comment)).

너무 제한적일 수 있는 구체적인 예가 있습니까?

함수가 캐리어 유형을 반환할 경우 해당 캐리어 유형에 관심 값을 넣을 수 있는 방법이 있어야 합니다. 그리고 중요한 것은, 이것을 제공하는 것이 어려운 일이 아니라고 생각합니다.

정당한 분석이라고 생각합니다. 나는 동의한다.

@SergioBenitez https://github.com/rust-lang/rfcs/pull/1859#issuecomment -279187967에서

따라서 문제는 제안된 제한 사항이 충분합니까? 성공 유형을 결정할 때 오류 사례 컨텍스트를 잘 사용하고 있습니까? 남용 가능성이 있습니까?

나는 미래에 대한 나의 경험으로 여기에 몇 가지 유용한 경우가 있을 수 있다고 말할 수 있습니다. 특히, 당신이 이야기하는 Poll 유형은 몇 가지 방법으로 처리될 수 있습니다. 때때로 우리는 NotReady 변형에서 뛰어 나와 본질적으로 Result 값을 남기고 싶습니다. 때때로 우리는 Ready 변형에만 관심이 있고 다른 변형(스케치에서와 같이) 중 하나에서 뛰어내리고 싶을 때가 있습니다. 성공 유형이 오류 유형에 의해 부분적으로 결정되도록 허용하면 이 두 경우를 모두 지원하고 기본적으로 컨텍스트를 사용하여 원하는 분해 유형을 결정하는 것이 더 그럴듯합니다.

OTOH, 이 줄을 따라 코드의 가독성에 대해 약간 걱정합니다. 이것은 단순히 오류 구성 요소를 변환하는 것과 질적으로 다릅니다. 즉, 기본적으로 ? 상황 정보에 따라 수행됩니다.

따라서 다음과 같이 _두 유형 모두를 유형 매개변수로 이동한 특성을 상상할 수 있습니다.

trait Try<T,E> {
    fn question(self) -> Either<T, E>;
}

그리고 그것을 사용하면 모든

let x: Result<_,_> = blah.poll()?; // early-return if NotReady
let x: Async<_> = blah.poll()?; // early-return if Error
let x: i32 = blah.poll()?; // early-return both NotReady and Errors

그러나 나는 이것이 작동하지 않는다는 것을 의미하기 때문에 확실히 나쁜 생각이라고 생각합니다.

println!("{}", z?);
z?.method();

무엇을 생성할지에 대한 유형 컨텍스트가 없기 때문입니다.

다른 버전은 다음과 같은 기능을 활성화하는 것입니다.

fn foo() -> Result<(), Error> {
    // `x` is an Async<i32> because NotReady doesn't fit in Result
    let x = something_that_returns_poll()?;
}
fn bar() -> Poll<(), Error> {
    // `x` is just i32 because we're in a Poll-returning method
    let x = something_that_returns_poll()?;
}

내 본능은 추론이 "?"에서 흘러 나온다는 것입니다. 너무 놀라운 것이 있으므로 이것은 "너무 영리한" 양동이에 있습니다.

비판적으로, 나는 그것을 갖지 않는 것이 너무 제한적이라고 생각하지 않습니다. my_result? -> Poll 함수의 Result 를 반환하는 메서드에서 Poll 에 ? 를 사용하는 것은 일반적인 것이 아니라 안티 패턴처럼 보이기 때문에 .wait(): T 와 같은 (가상의) 전용 메서드를 사용합니다. .ready(): Option<T> (완료 여부 확인) 모드를 선택하는 것이 어쨌든 더 나을 것입니다.

"흥미롭다" https://play.rust-lang.org/?gist=d3f2cd403981a631f30eba2c3166c1f4&version=nightly&mode=debug

나는 이 try (do catch) 블록이 마음에 들지 않습니다. 이 블록은 초보자에게 그다지 친숙하지 않은 것 같습니다.

여러 의견에 퍼져 있는 제안의 현재 상태를 조합하려고 합니다. 현재 제안된 특성 세트( Error 관련 유형 삭제)에 대한 단일 요약이 있습니까?

이 스레드의 초기에 Try 를 오류 특성과 별개로 분할하는 것에 대한 주석을 보았습니다. 해당 분할을 구현할 계획이 있습니까?

물음표에서 Result<T, E> 에서 모든 유형의 Other<T2, E> 투명하게 변환하는 것이 유용할 것입니다. 이렇게 하면 기존 IO 함수를 보다 전문화된 함수 내에서 멋진 구문으로 호출할 수 있습니다(예: 게으름) 반환 유형.

pub fn async_handler() -> AsyncResult<()> {
    let mut file = File::create("foo.txt")?;
    AsyncResult::lazy(move || {
        file.write_all(b"Hello, world!")?;
        AsyncResult::Ok(())
    })
}

의미상 이것은 From::from(E) -> Other<T2, E> 처럼 느껴지지만 From 은 현재 기존 Result -동등한 Try 구현으로 제한됩니다.

NoneError 에는 별도의 추적 문제가 있어야 한다고 생각합니다. Try 특성이 안정화되지 않더라도 ? 에 Option 훨씬 더 인체공학적이므로 NoneError 는 안정화되어야 합니다. struct MyCustomSemanthicalError; 와 같은 오류 또는 Default 구현 오류에 대해 이것을 고려하십시오. None 는 MyCustomSeemanthicalError 를 통해 From<NoneError> MyCustomSeemanthicalError 로 쉽게 변환할 수 있습니다.

https://github.com/rust-analyzer/rust-analyzer/ 에서 작업하면서, 특히 반환 유형이 Result<Option<T>, E> 때 ? 연산자의 불충분함과 약간 다른 페이퍼컷을 만났습니다 Result<Option<T>, E> .

이 유형의 경우 ? 을 위해 효과적으로 설탕을 제거하는 것이 합리적입니다.

match value? {
    None => return Ok(None),
    Some(it)=>it,
}

여기서 value 는 Result<Option<V>, E> 유형이거나 다음과 같습니다.

value?

여기서 value 는 Result<V, E> 입니다. 나는 이것이 가능하다고 생각되면 표준 라이브러리 구현 Try 에 대한 다음과 같은 방법으로 Option<T> , 내가 명시 적으로 테스트하지 않은 내가 전문화 문제가있을 수 있습니다 생각하지만.

enum NoneError<E> {
    None,
    Err(E),
}

impl From<T> for NoneError<T> {
    fn from(v: T) -> NoneError<T> {
        NoneError:Err(v)
    }
}

impl<T, E> std::Ops::Try for Result<Option<T>, E> {
    type OK = T;
    type Error = NoneError<E>;
    fn into_result(self) -> Result<Self::OK, Self::Error> {
        match self {
            Ok(option) => {
                if let Some(inner) = option {
                    Ok(inner)
                } else {
                    Err(NoneError::None)
                }
            }
            Err(error) => {
                Err(NoneError::Err(error));
            }
        }
    }
    fn from_error(v: Self::Error) -> Self {
        match v {
            NoneError::Err(error) => Err(error),
            None => Some(None),
        }
    }
    fn from_ok(v: Self::OK) -> Self {
        Ok(Some(v))
    }
}

impl<T> std::Ops::Try for Option<T> {
    type OK = T;
    type Error = NoneError<!>;
    fn into_result(self) -> Result<Self::OK, Self::Error> {
        match self {
            None => Err(NoneError::None),
            Some(v) => Ok(v),
        }
    }
    fn from_error(v: Self::Error) -> Self {
        match v {
            NoneError::None => Some(None),
            _ => unreachable!("Value of type ! obtained"),
        }
    }
    fn from_ok(v: Self::OK) -> Self {
        Ok(v)
    }
}

https://github.com/rust-lang/rust/issues/31436#issuecomment -441408288에서 다시 게시합니다. 이에 대해 언급하고 싶었지만 잘못된 문제라고 생각했기 때문입니다.

본질적으로 내가 가진 상황은 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 연산자가 이와 같은 것을 지원할 수 있다면 좋을 것입니다.

@joshtriplett 시간 을 들여 다시 https://github.com/rust-lang/rust/compare/master...scottmcm :try-trait-v2에서 제안의 작업 프로토타입을 구성하여 구체적으로 만들었습니다. 나는 그것으로 몇 가지 더 많은 것을 시도하기를 바랍니다.

@scottmcm 변경 사항에 대한 상위 수준 설명이 있습니까?

@scottmcm FWIW 레이온에서도 변경을 시도했습니다.
https://github.com/rayon-rs/rayon/compare/master...cuviper :try-trait-v2
(여전히 불안정한 항목이 아닌 개인 사본을 사용 중)

그렇다면 Option NoneError를 변환하는 솔루션은 무엇입니까? Try Trait를 구현하기 때문에 해당 특정(불안정한?) 기능을 사용하도록 설정하지 않는 한 컴파일되지 않는 것 같습니다.

따라서 기본적으로 ? 내가 아는 한 옵션이 있는 연산자?

@omarabid , 연산자는 Option 또는 Result 와 함께 사용하기에 안정적이지만 안정될 때까지 Try 를 일반 제약 조건으로 사용할 수 없습니다. NoneError 를 전혀 포함할 필요가 없으므로 Option 반환하는 함수에서 Option 에 ? 를 사용하는 것은 완벽합니다. 유형을 지우면 Result 반환할 수도 있습니다.

use std::fmt::Debug;

pub struct Error(Box<dyn Debug>);

impl<T: Debug + 'static> From<T> for Error {
    fn from(error: T) -> Self {
        Error(Box::new(error))
    }
}

pub fn try_get<T>(slice: &[T], index: usize) -> Result<&T, Error> {
    Ok(slice.get(index)?)
}

( 놀이터 )

@scottmcm , 프로토타입 try-trait-v2 이 예제는 실패합니다!

내 예제가 중단되는 것을 원하지 않으면 try-trait-v2 다음과 같은 것이 필요합니다.

#[unstable(feature = "try_trait_v2", issue = "42327")]
impl<T, U, E: From<NoneError>> ops::Bubble<Result<U, E>> for Option<T> {
    fn bubble(self) -> ops::ControlFlow<T, Result<U, E>> {
        match self {
            Some(x) => ops::ControlFlow::Continue(x),
            None => ops::ControlFlow::Break(Err(E::from(NoneError))),
        }
    }
}

이 기능의 현재 상태는 무엇입니까?

이터레이터에 대해 try_fold 를 구현하는 문서에 대한 PR #62606이 안정화되면 다시 열어야 합니다.

편집: ~ scottmcm에 대한 추적 항목으로 작업을 업데이트했습니다.

Try 특성을 이 스레드에서 제안된 대안으로 대체할 계획이 있습니까? @scottmcm이 제안한 버전 은 괜찮은 것 같습니다. Option 와 함께 ? 연산자를 계속 사용하고 싶습니다. Option 에 Result 의미 체계를 강제하지 않도록 Try 트레잇을 변경해야 한다고 생각합니다. Option .

@scottmcm 의 대안을 사용하면 ? 와 함께 Option 하고 NoneError 있습니다. 나는 Try 특성이 " Option 의 '실패'를 나타내는 유형을 인공적으로 정의할 필요가 없다"는 @nikomatsakis ( comment )에 동의합니다.

pub struct Error(Box<dyn std::fmt::Debug>);
impl<T: std::fmt::Debug + 'static> From<T> for Error { fn from(error : T) -> Self { Error(Box::new(error)) } }
type Result<T> = std::result::Result<T, Error>;

여기 초심자, 나는 얻고 싶은 것에 약간 고집이 있었습니까? 자동으로 모든 오류 및 옵션 지우기를 입력합니다.
다른 가능한 솔루션을 구현할 수 없는 이유를 이해하려고 너무 많은 시간을 보낸 후 @cuviper 가 내가 얻을 수 있는 것과 가장 가깝다는 것을 알았습니다.
몇 가지 설명이 도움이 되었지만 적어도 Rust 메타프로그래밍의 몇 가지 제한 사항에 대해 자세히 알게 되었습니다.
그래서 그것을 이해하고 구체적인 용어로 설명하려고 노력했습니다.
이 스레드는 나 같은 사람이 이것에 걸려 넘어지도록 도울 수 있는 가장 가능성 있는 교차로인 것 같습니다. 자유롭게 수정하십시오.

• StdError 대신 디버그(StdError 및 NoneError에 공통) 사용:
  일반 From<T: StdError> for Error 및 특수 From<NoneError> for Error 충돌
  NoneError가 StdError를 구현하면 모호하기 때문에 (분명히 기본값이라도 재정의를 허용하지 않고 독점성을 적용합니다)
  이것은 지원되지 않는 "음수 경계"로 해결할 수 있습니다. 아마도 이것이 유일한 사용 사례이기 때문일 것입니다. (전문화 이상)
  NoneError에 대한 impl StdError는 StdError 또는 NoneError와 함께만 정의할 수 있으므로 모든 다운스트림에서 일관됩니다.
• 오류는 별칭일 수 없습니다.
  type Error = Box<Debug> 는 From<T:Debug> for Error 를 From<T> for T 와 충돌하게 하는 디버그를 바인딩합니다(멱등성을 위한 재귀 From)

따라서 Error는 Debug를 구현할 수 없기 때문에 전이적 Debug를 사용하여 결과로 래핑 해제하는 도우미를 원할 수 있습니다.

fn from<T>(result : Result<T>) -> std::result::Result<T, Box<dyn std::fmt::Debug>> { match result { Ok(t) => Ok(t), Err(e) => Err(e.0) } }

impl From<Result<T>> for StdResult<T> 또는 Into<StdResult> for Result<T> 수 없습니다(업스트림 유형에 대한 업스트림 특성을 암시할 수 없음).

예를 들어 이를 사용하여 Termination에 대한 디버그 반환을 얻을 수 있습니다.

fn main() -> std::result::Result<(), Box<dyn std::fmt::Debug>> { from(run()) }

사악한 생각: 아마도 ? 연산자는 모나딕 ​​바인드를 나타낼 수 있으므로

let x: i32 = something?;
rest of function body

된다

Monad::bind(something, fn(x) {
    rest of function body
})

끔찍한 생각이지만 내 안의 괴짜를 기쁘게 합니다.

@derekdreery return 및 continue 와 같은 명령형 제어 흐름에서는 잘 작동하지 않는다고 생각합니다.

? 연산자의 의미는 이미 안정적입니다. 실제 Try 특성만 불안정하고 모든 변경 사항은 Option 및 Result 대해 동일한 안정적인 효과를 유지해야 합니다.

@KrishnaSannasi

@derekdreery 반환 및 계속과 같은 명령형 제어 흐름에서 잘 작동하지 않을 것이라고 생각합니다.

나는 이 말에 동의한다.

@cuviper

의 의미는 ? 운영자는 이미 안정적입니다. 실제 Try 트레이트만 불안정하며 모든 변경 사항은 Option 및 Result에 대해 동일한 안정적인 효과를 유지해야 합니다.

이것은 모든 시대에도 마찬가지입니까?

좀 더 일반적으로 말하자면 .await , ?/ early return, Option::map, Result::map, Iterator::map in rust, 그러나 이것들이 모두 어떤 구조를 공유한다는 것을 이해하면 분명히 더 나은 프로그래머가 되는 데 도움이 됩니다.

OT가 되어 죄송합니다.

신기원/에디션이 ? 디슈가링을 변경할 수 있는지 확실하지 않지만 매크로와 같은 교차 상자 문제가 많이 복잡해집니다.

안정성 보장 및 에포크 RFC에 대한 나의 해석은 ? 동작(설탕 또는 기타)이 변경될 수 있지만 Option / Result 유형에 대한 현재 동작은 그대로 유지되어야 한다는 것입니다. 그것을 깨는 것은 우리가 정당화할 수 있는 것보다 훨씬 더 많은 이탈을 야기할 것이기 때문입니다.

Option 가 Result 대한 유형 별칭이라면 어떻게 됩니까? 예를 들어 type Option<T> = Result<T, NoValue> , Option::<T>::Some(x) = Result::<T, NoValue>::Ok(x) , Option::<T>::None = Result::<T, NoValue>::Err(NoValue) ? 구현하려면 마법이 필요하고 현재 언어 환경에서는 현실적이지 않지만 탐색할 가치가 있을 수 있습니다.

Option Result 가 고유한 유형인 것에 의존하는 특성 impls가 있기 때문에 이 변경을 수행할 수 없습니다.

우리가 그것을 무시하면, 우리는 한 단계 더 걸릴 수 있고, 심지어 있도록 bool 별칭을 Result<True, False> , True 및 False 단위 유형입니다.

Try impl를 () 단위로 추가하는 것이 고려되었습니까? 아무 것도 반환하지 않는 함수의 경우, 로깅 콜백과 같이 중요하지 않은 함수에서 오류가 발생한 경우 조기 반환이 여전히 유용할 수 있습니다. 아니면 어떤 상황에서도 오류를 조용히 무시하지 않는 것이 바람직하기 때문에 유닛이 제외되었습니까?

아니면 어떤 상황에서도 오류를 조용히 무시하지 않는 것이 바람직하기 때문에 유닛이 제외되었습니까?

이것. 중요하지 않은 컨텍스트에서 오류를 무시하려면 unwrap 또는 그 변형 중 하나를 사용해야 합니다.

foo() -> () 와 같은 것에 ? 를 사용할 수 있다는 것은 조건부 컴파일 컨텍스트에서 매우 유용할 것이며 강력하게 고려해야 합니다. 나는 그것이 당신의 질문과 다르다고 생각합니다.

unwrap 또는 그 변형 중 하나를 사용해야 합니다.

unwrap() 는 패닉을 유발하므로 중요하지 않은 컨텍스트에서는 사용하지 않는 것이 좋습니다. 단순 반환이 필요한 상황에서는 적절하지 않습니다. 소스 코드에서 ? 의 명시적이고 가시적인 사용으로 인해 ? 가 완전히 "침묵"되지 않는다는 주장을 할 수 있습니다. 이런 식으로 ? 및 unwrap() 는 반환 의미가 다를 뿐 단위 함수와 유사합니다. 내가 볼 수있는 유일한 차이점은 unwrap() 는 가시적인 부작용을 만들고(프로그램 중단 / 스택 추적 인쇄) ? 는 그렇지 않다는 것입니다.

현재 단위 함수에서 조기 반환의 인체 공학은 Result 또는 Option 반환하는 것보다 상당히 나쁩니다. 아마도 이러한 상황은 사용자 가 이러한 경우 Result 또는 Option 의 반환 유형을 사용해야 하고 API를 변경하도록 인센티브를 제공하기 때문에 바람직할 수 있습니다. 어느 쪽이든 PR이나 문서에 단위 반환 유형에 대한 설명을 포함하는 것이 좋습니다.

foo() -> () 와 같은 것에 ? 를 사용할 수 있다는 것은 조건부 컴파일 컨텍스트에서 매우 유용할 것이며 강력하게 고려해야 합니다. 나는 그것이 당신의 질문과 다르다고 생각합니다.

어떻게 작동할까요? 항상 Ok(())로 평가하고 무시하시겠습니까?

또한 이것을 어디에 사용하고 싶은지 예를 들어주실 수 있습니까?

예, MyCollection::push와 같은 항목은 컴파일 시간 구성에 따라 Result<(), AllocError> 반환 값 또는 () 반환 값을 가질 수 있다는 생각이 들었습니다. 컬렉션을 사용하는 중간 코드는 그것에 대해 생각할 필요가 없으므로 반환 유형이 () 경우에도 _항상_ ? 를 사용할 수 있다면 편리할 것입니다.

거의 3년이 지난 지금, 이 문제가 해결되기에 더 가깝습니까?

@Lokathor 는 반환 유형 Result<Result<X,Y>,Z> 또는 이와 유사한 것이 가능하지 않은 경우에만 작동합니다. 하지만 그것은. 따라서 불가능합니다.

계층화된 결과가 문제를 일으키는 이유를 이해하지 못합니다. 자세히 설명해 주시겠습니까?

상호 참조 목적을 위해 @dureuill이 내부에 대안 공식을 제안했습니다.

https://internals.rust-lang.org/t/a-slightly-more-general-easier-to-implement-alternative-to-the-try-trait/12034

@로카토르
좋아, 나는 그것에 대해 더 깊이 생각했고 내가 오히려 좋은 설명을 찾았을 수도 있다고 생각합니다.

주석 사용

문제는 반환 유형의 해석이나 이상한 주석이 코드를 복잡하게 만드는 것입니다. 가능하지만 코드를 읽기가 더 어려워집니다. (사전 조건: #[debug_result] 은 원하는 동작을 적용하고 Result::Err(...) 를 반환하는 대신 릴리스 모드에서 패닉하도록 함수를 수정하고 Result::Ok 풀지만 그 부분은 까다롭습니다)

#[debug_result]
fn f() -> Result<X, Y>;

#[debug_result]
fn f2() -> Result<Result<A, B>, Y>;

#[debug_result]
fn g() -> Result<X, Y> {
    // #[debug_result_spoiled]
    let w = f();
    // w could have type X or `Result<X,Y>` based on a #[cfg(debug_...)]
    // the following line would currently only work half of the time
    // we would modify the behavoir of `?` to a no-op if #[cfg(not(debug_...))]
    // and `w` was marked as `#[debug_result]`-spoiled
    let x = w?;

    // but it gets worse; what's with the following:
    let y = f2();
    let z = y?;
    // it has completely different sematics based on a #[cfg(debug_...)],
    // but would (currently?) print no warnings or errors at all,
    // and the type of z would be differently.

    Ok(z)
}

따라서 코드를 읽기가 더 어려워집니다.
단순히 ? 의 동작을 no-op으로 수정할 수 없습니다.
특히 #[debug_result] 의 반환 값이 임시 변수에 저장되고 나중에 ? 연산자로 "시도 전파"되는 경우. 그것은 ? 의 의미를 정말로 혼란스럽게 만들 것입니다. 왜냐하면 "작성 시간"에 반드시 알려지지 않거나 소스 코드를 읽는 것만으로는 추측하기 어려울 수 있는 많은 "변수"에 의존하기 때문입니다. #[debug_result] 는 함수 값이 할당된 변수를 망칠 필요가 있지만, 하나의 함수가 #[debug_result] 로 표시되고 다른 하나는 표시되지 않으면 작동하지 않습니다. 예를 들어 다음은 유형 오류입니다.

// f3 is not annotated
fn f3() -> Result<X, Y>;

// later inside of a function:
   // z2 needs to be both marked spoiled and non-spoiled -> type error
   let z2 = if a() {
       f3()
   } else {
       f()
   };
   // althrough the following would be possible:
   let z2_ = if a() {
       f3()?
   } else {
       f()?
   };

대안: 새 유형 사용

"정리한" 솔루션은 특정 컴파일 플래그가 설정되고 오류로 구성될 때 패닉을 일으키는 DebugResult<T, E> 유형일 수 있지만 그렇지 않으면 Result<T, E> 와 동일합니다. 그러나 그것은 현재 제안으로도 가능할 것이라고 생각합니다.

@zserik 의 마지막 게시물에 답장: 설명하신 매크로는 무의미합니다. 빌드 구성을 기반으로 하는 반환 유형의 함수를 청구하면 수행된 방식에 관계없이 유일한 빌드 구성을 제외한 모든 가능한 빌드 구성에서 기능 결과에 대한 모든 일치가 중단됩니다.

@tema3210 알겠습니다 . @Lokathor 의 아이디어는 일반적으로 실제로 작동하지 않는다는 점을 지적하고 싶었습니다. 부분적으로 작동할 수 있는 유일한 것은 다음과 같지만 많은 제한 사항이 있기 때문에 장기적으로 가치가 없다고 생각합니다.

// the result of the fn *must* have Try<Ok=()>
// btw. the macro could be already implemented with a proc_macro today.
#[debug_result]
fn x() -> Result<(), XError> {
  /* ..{xbody}.. */
}

// e.g. evaluates roughly to:
//..begin eval
fn x_inner() -> Result<(), XError> {
  /* ..{xbody}.. */
}

#[cfg(panic_on_err)]
fn x() {
  let _: () = x_inner().unwrap();
}
#[cfg(not(panic_on_err))]
fn x() -> Result<(), XError> {
  x_innner()
}

//..end eval

fn y() -> Result<(), YError> {
  /* ... */
  // #[debug_result] results can't be matched on and can't be assigned to a
  // variable, they only can be used together with `?`, which would create
  // an asymetry in the type system, but could otherwise work, althrough
  // usage would be extremely restricted.
  x()?;
  // e.g. the following would fail to compile because capturing the result
  // is not allowed
  if let Err(z) = x() {
    // ...
  }
}

@zserik 실제로 이런 형태를 취하는 것이 가능합니까?

#[cfg(panic_on_err)]
fn x() -> Result<(), !> {
  let _: () = x_inner().unwrap();
}

#[cfg(not(panic_on_err))]
fn x() -> Result<(), XError> {
  x_innner()
}

좋아, 좋은 생각이야.

이것이 안정화 이전에 설명되어야 하는 것인지 확실하지 않지만 오류 반환 추적을 구현하는 데 관심이 있으며 Try 특성 또는 적어도 제공된 impl에 대한 변경이 포함된다고 생각합니다. Result 를 사용하여 작동하도록 합니다. 결국 나는 이것을 RFC로 바꿀 계획이지만, 내가 말한 RFC를 작성하는 데 시간이 걸릴 경우를 대비하여 나중에 추가할 수 없도록 하는 방식으로 try 특성이 안정화되지 않았는지 확인하고 싶습니다. 기본 아이디어는 이것이다.

이전 버전과의 호환성을 유지하기 위해 T에 대한 특수화 및 기본 impl을 사용하는 추적 정보를 전달하는 데 사용하는 특성이 있습니다.

pub trait Track {
    fn track(&mut self, location: &'static Location<'static>);
}

default impl<T> Track for T {
    fn track(&mut self, _: &'static Location<'static>) {}
}

그리고 당신은 수정 Try 대한 구현 Result 사용하여 track_caller 하고 내부 형으로이 정보를 전달,

    #[track_caller]
    fn from_error(mut v: Self::Error) -> Self {
        v.track(Location::caller());
        Self::Err(v)
    }

그런 다음 추적을 구현하기 위해 역추적을 수집하려는 유형에 대해

#[derive(Debug, Default)]
pub struct ReturnTrace {
    frames: Vec<&'static Location<'static>>,
}

impl Track for ReturnTrace {
    fn track(&mut self, location: &'static Location<'static>) {
        self.frames.push(location);
    }
}

사용법은 다음과 같이 끝납니다.

#![feature(try_blocks)]
use error_return_trace::{MyResult, ReturnTrace};

fn main() {
    let trace = match one() {
        MyResult::Ok(()) => unreachable!(),
        MyResult::Err(trace) => trace,
    };

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

fn one() -> MyResult<(), ReturnTrace> {
    try { two()? }
}

fn two() -> MyResult<(), ReturnTrace> {
    MyResult::Err(ReturnTrace::default())?
}

그리고 역추적의 아주 형편없는 버전의 출력은 다음과 같습니다.

ReturnTrace { frames: [Location { file: "examples/usage.rs", line: 18, col: 42 }, Location { file: "examples/usage.rs", line: 14, col: 16 }] }

그리고 여기에 행동에 대한 개념 증명이 있습니다. https://github.com/yaahc/error-return-traces

나는 우리가 트레이트 구현 자를 위해 변환할 수 있는 오류 유형은 하나만 부족할 수 있다고 생각하여 다음과 같은 인터페이스를 제공할 수 있습니다.

trait Try{
     type Error;
     type Ok;
     fn into_result(self)->Result<Self::Ok,Self::Error>;
     fn from_ok(val: Self::Ok)->Self;
     fn from_error<T>(val: T)->Self;
}

컴파일러는 From::from 호출을 피하기 위해 from_error 단일형화할 수 있으며 다른 오류 유형에 대해 수동으로 impl 메서드를 제공할 수 있으므로 ? 연산자가 다른 "언래핑" 기능을 수행할 수 있습니다. 오류 유형.

 fn from_error<T>(val: T)->Self;

작성된 대로 구현자는 _모든_ 크기의 T 를 제한 없이 수락해야 합니다. 이것을 사용자 정의 제한하도록 하려면 Try<T> 와 같은 특성 매개변수여야 합니다. 이것은 @scottmcm 이 https://github.com/rust-lang/rust/issues/42327#issuecomment-457353299에 있었던 TryBlock / Bubble<Other> 조합과 유사 합니다.

작성된 대로 구현자는 _any_ 크기의 T 를 제한 없이 수락해야 합니다. 이것을 사용자 정의 제한하려면 Try<T> 와 같은 특성 매개변수여야 합니다. 이것은 @scottmcm 이 #42327(comment) 에 있었던 TryBlock / Bubble<Other> 조합과 유사 합니다.

사용법은 다음과 같아야 합니다.

trait Try{
     //same from above
}
struct Dummy {
    a: u8,
}
struct Err1();
struct Err2();
impl Try for Dummy {
    type Ok=();
    type Error=();

    fn into_result(self)->Result<Self::Ok,Self::Error>{
        std::result::Result::Ok(())
    }
    fn from_ok(val: Self::Ok)->Self{
        Self{a: 0u8}
    }
    fn from_error<T>(val: Err1)->Self where T == Err1{
        Self{a: 1u8}
    }
    fn from_error<T>(val: Err2)->Self where T == Err2{
        Self{a: 2u8}
    }
}

Try와 TryFromError를 분리해야 합니다. 나는 원래 제안 fwiw보다 그것을 더 좋아하지만 새로운 RFC가 필요할 것이라고 생각합니다.

(그리고 나는 여전히 "시도"대신 "전파"라고 불러야한다고 생각하지만 나는 탈선합니다)

@tema3210 나는 당신의 의도를 이해한다고 생각하지만 그것은 유효한 Rust가 아닙니다.

@SoniEx2

Try와 TryFromError를 분리해야 합니다.

맞아, 그래서 내가 TryBlock / Bubble<Other> 디자인을 언급한 것이다. 명명 선택에 대해 논쟁할 수 있지만 조기 반환이 항상 _오류_에 관한 것은 아니라는 아이디어입니다. 예를 들어, 많은 내부 Iterator 메소드가 사용자 정의 LoopState 유형을 사용하고 있습니다. find 와 같은 경우 찾고 있는 것을 찾는 것은 오류가 아니지만 여기서 반복을 중지하고 싶습니다.

https://github.com/rust-lang/rust/blob/3360cc3a0ea33c84d0b0b1163107b1c1acbf2a69/src/libcore/iter/mod.rs#L375 -L378

명명 선택에 대해 논쟁할 수 있지만 조기 반환이 항상 오류 자체에 관한 것은 아니라는 생각이었습니다.

정확히 내가 "시도"라는 이름을 좋아하지 않고 "전파"라는 이름을 선호하는 이유는 "조기"를 "전파"하기 때문입니다. return :p

(이것이 의미가 있는지 확실하지 않습니까? 지난번에 "전파"라는 것을 언급했을 때 어떤 이유로 나에게만 의미가 있었고 다른 사람들에게 설명할 수 없었습니다.)

디버그 정보(예: 파일/라인 번호)를 기록하기 위해 로그 후크 fe를 추가하기 위해 기본 ? 동작 fe를 덮어쓰려고 할 때 이 특성이 도움이 될까요?

현재 stdlib 매크로 덮어쓰기가 지원되지만 ? 연산자가 명시적으로 try! 매크로로 변환되지 않는 것 같습니다. 운이 없었어.

@stevenroose Try 트레잇 에만 지원을 추가하려면 ? "발생한" 위치에 대한 파일 위치 정보를 포함하도록 Try 트레잇을 수정해야 합니다. .

@stevenroose Try 트레잇 에만 지원을 추가하려면 ? "발생한" 위치에 대한 파일 위치 정보를 포함하도록 Try 트레잇을 수정해야 합니다. .

이것은 사실이 아닙니다. #[track_caller]는 특성 정의에 주석이 포함되지 않은 경우에도 특성 impls에 사용할 수 있습니다.

@stevenroose 가 귀하의 질문에 대답합니다. 예, 하지만 모든 ? 위치를 인쇄하는 데 관심이 있다면 오류가 전파되는 위의 오류 반환 추적 주석을 확인해야 합니다.

https://github.com/rust-lang/rust/issues/42327#issuecomment -619218371

누군가 이미 이것을 언급했는지 확실하지 않습니다. impl Try for bool , 아마도 Try<Ok=(), Error=FalseError> ?
우리가 이런 일을 할 수 있도록

fn check_key(v: Vec<A>, key: usize) -> bool {
  let x = v.get_mut(key)?; // Option
  x.is_valid()?; // bool
  x.transform()?; // Result
  true
}

이제 ? 가 코드를 훨씬 더 명확하게 만들 수 있다고 생각하는 대부분의 경우에 반환 유형 Option<()> 을 사용해야 합니다.

누군가 이미 이것을 언급했는지 확실하지 않습니다. impl Try for bool , 아마도 Try<Ok=(), Error=FalseError> ?

이것은 만들 것 Try 처럼 행동 && 에 운영자 bool 들. 위에서 다른 사람들이 지적했듯이 성공 시 단락에 대한 사용 사례도 있습니다. 이 경우 Try 는 || 처럼 작동해야 합니다. && 및 || 연산자는 입력하는 데 시간이 오래 걸리지 않기 때문에 이 구현의 이점도 별로 없습니다.

@calebsander 친절한 답변 감사합니다.
그것은 몇몇 간단한 경우에 해당하지만, 자주 그런 경우는 아니라고 생각합니다. 특히 표현식에서 let x = v.get_mut(key)? 와 같은 대입문을 가질 수 없었습니다.
&& 및 || 가 항상 트릭을 수행하는 경우 Option 및 Error 대해 Option .unwrap_or_else() , .and_then() 로 플레이할 수도 있습니다. Error 케이스.
흐르는 코드를 && 및 || 표현할 수 있습니까?

fn check_key(v: Vec<A>, key: usize) -> bool {
  let x = v.get_mut(key)?; // Option
  x.not_valid().not()?; // bool
  for i in x.iter() {
    if i == 1 { return true }
    if i == 2 { return false }
    debug!("get {}" i);
  }
  let y = x.transform()?; // Result
  y == 1
}

true 실패를 의미하고 false 성공을 의미하는 일부 조건의 경우 !expr? 가 혼동될 수 있지만 expr.not()? 를 사용하여 트릭을 수행할 수 있습니다(참고: ops::Try , 우리는 항상 false 대해 Error )

그것은 몇몇 간단한 경우에 해당하지만, 자주 그런 경우는 아니라고 생각합니다. 특히 표현식에서 let x = v.get_mut(key)? 와 같은 대입문을 가질 수 없었습니다.

글쎄, 내가 당신의 제안을 오해하지 않는 한 Try<Ok = (), Error = FalseError> 대해 bool Try<Ok = (), Error = FalseError> 를 구현하는 것은 이것을 허용하지 않습니다. ? 연산자가 None 를 false 로 변환할 수 있도록 impl From<NoneError> for FalseError 도 필요합니다. (그리고 마찬가지로 적용 할 경우 ? 에 Result<T, E> 반환하는 내부 함수 bool , 당신이 필요 impl From<E> for FalseError . 나는 그런 생각 일괄 구현은 문제가 될 수 있습니다.) 반환 값 Result<bool, bool> 문제가 없는 경우 some_option().ok_or(false)? 및 some_result().map_err(|_| false)? 를 사용할 수도 있습니다( .unwrap_or_else(|err| err) 축소할 수 있음).

다른 Try 오류를 bool 로 변환하는 문제는 제쳐두고 bool 대해 제안하는 Try 구현은 && 연산자

fn using_try() -> bool {
    some_bool()?;
    some_bool()?;
    some_bool()
}

그리고

fn using_and() -> bool {
    some_bool() &&
    some_bool() &&
    some_bool()
}

(물론 () 가 아닌 값을 반환하는 if 및 loop 같은 제어 흐름은 번역하기가 덜 간단합니다.)

true 실패를 의미하고 false 성공을 의미하는 일부 조건의 경우 !expr? 가 혼동될 수 있지만 expr.not()? 를 사용하여 트릭을 수행할 수 있습니다(참고: ops::Try , 우리는 항상 false for Error )

false 가 Error 사례를 나타내야 한다는 것이 명확하지 않습니다. (예를 들어, Iterator.all() 는 false 가 단락되기를 원하지만 Iterator::any() 는 대신 true 를 원합니다.) 지적했듯이, ? 전달된 값을 반전(및 함수의 반환 값도 반전)하여 반대 단락 동작. 하지만 그렇게 해서 가독성이 좋은 코드가 나올 것이라고는 생각하지 않습니다. 두 가지 다른 동작을 구현하는 별도의 struct s And(bool) 및 Or(bool) 를 갖는 것이 더 합리적일 수 있습니다.

그리고 마찬가지로 신청하려면 ? 결과에bool을 반환하는 함수 내에서 다음을 수행해야 합니다.FalseError의 경우. 나는 그러한 전면적인 구현이 문제가 될 것이라고 생각합니다.

아니요, 저는 impl From<T> for FalseError 하고 싶지 않습니다. 아마도 result.ok()?

false가 오류 사례를 나타내야 하는지는 분명하지 않습니다.

true 를 Some 매핑하는 bool::then 가 있을 때 자연스럽게 생각합니다.

내가 놓쳤다면 용서해 주세요 - 왜 NoneError impl std::error::Error ? 이것은 Box<dyn Error> 또는 이와 유사한 것을 반환하는 모든 함수에 쓸모가 없습니다.

내가 놓쳤다면 용서해 주세요 - 왜 NoneError impl std::error::Error ? 이것은 Box<dyn Error> 또는 이와 유사한 것을 반환하는 모든 함수에 쓸모가 없습니다.

전문가는 아니지만 "뭔가 None 이고 Some 가 될 것으로 예상했습니다"에 대한 유용한 오류 메시지를 작성하려고 시도하는 데 심각한 문제가 있음을 알 수 있습니다(기본적으로 여기에서 얻을 수 있습니다 -- 약간의 진단 메시지). 내 경험상 Option::ok_or_else 결합자를 대신 사용하여 다른 오류 유형을 사용하는 것이 항상 가장 합리적이었습니다.

@ErichDonGubler에 동의합니다. ? 를 Option ? 와 함께 사용할 수 없다는 것은 매우 성가신 일입니다. 그러나 이는 타당한 이유가 있으며 언어 사용자로서 오류를 올바르게 처리하는 것이 모든 사람에게 가장 좋은 일이라고 생각합니다. ? 수행하는 대신 None 오류 컨텍스트를 바인딩하는 추가 작업을 수행하는 것은 정말, 정말 짜증나는 일이지만, 오류를 제대로 전달하도록 강제하므로 충분히 가치가 있습니다.

None 오류로 해석할 수 있는 유일한 경우는 프로토타이핑이 매우 거칠 때입니다. Option::todo_err() 호출과 같은 것을 추가하면 내부 값의 Ok 가 반환되지만 None 에 패닉이 발생할 것이라고 생각했습니다. 코드 작성의 "거친 프로토타이핑" 모드의 필요성을 분석할 때까지는 매우 직관적이지 않습니다. Ok(my_option.unwrap()) 와 매우 유사하지만 Ok(...) 래핑이 필요하지 않습니다. 또한 "todo" 특성을 명시적으로 지정하여 프로덕션 로직에서 이 코드를 제거하고 적절한 오류 바인딩으로 대체하려는 의도를 전달합니다.

그러나 없음에 당황할 것입니다

이것을 unwrap 놔둬야 한다고 강하게 느낍니다. todo_err을 추가하면 실제 오류 유형을 반환해야 하므로 반환할 오류 유형에 대한 질문이 필요합니다.

또한 나는 fn todo_err(self) -> Result<Self, !> 이 안정화를 위해 ! 를 요구하는 명백한 문제가 있을 것이라고 생각합니다. 어, 글쎄요, 언젠가.

내 유스 케이스는 실제로 오류에 대해 너무 신경 쓰지 않는 거친 프로토 타이핑입니다. NoneError 전체가 귀하가 나열한 이러한 문제로 고통받고 있지 않습니까? 그것이 존재해야 한다고 결정되면(적어도 프로토타이핑에 있어서는 좋은 일이라고 생각합니다), Error 라는 이름이 붙은 것처럼 암시해야 한다고 생각합니다.

이 impl이 없는 유형 때문에 .ok_or("error msg") 를 두드리기만 했습니다. 이 방법도 작동하지만 덜 편리합니다.