Rust: RFC 1937에 대한 추적 문제: `main`의 `?`

종료 상태는 어떻게 처리됩니까?

@Screwtapello의 이 댓글 은 FCP에 대한 응답으로 RFC를 변경하기에는 FCP의 끝 부분에 너무 가깝게 작성된 것 같습니다.

요컨대: RFC는 근거는 있지만 불분명하고 약간 비정상적인 결과를 생성하는 근거 로 실패 시 2를 반환할 것을 제안합니다 . 가장 놀라운 것은 프로그램이 성공 또는 실패보다 더 자세한 정보를 원한다는 표시가 없을 때 1을 반환하는 것입니다. 이것이 우리가 RFC 프로세스를 왜곡하고 있다는 느낌 없이 논의할 수 있을 만큼 충분히 자전거 타기입니까? 아니면 이제 이 특정 구현 세부 사항에 잠겨 있습니까?

구현 세부 사항은 아닙니다. 그렇죠?

일부 스크립트는 하위 프로세스에서 정보를 가져오는 방법으로 종료 코드를 사용합니다.

이것은 특히 하위 프로세스(Rust에서 구현된)가 바이너리 "모든 것이 정상"/"뭔가 잘못되었습니다" 외에 제공할 정보가 없는 경우에 관한 것입니다.

일부 스크립트는 하위 프로세스에서 정보를 가져오는 방법으로 종료 코드를 사용합니다.

그 동작은 0이 아닌 것은 실패를 의미한다는 점에서 _except_ 호출되는 프로그램에 항상 크게 의존합니다. 주 기능 래퍼와 조회 테이블이 있는 std::process::exit 가 무엇을 하든 더 명확한 종료 상태를 원하는 사람들에게 최상의 옵션으로 남을 것이라는 점을 감안할 때 이것은 거의 중요하지 않은 세부 사항처럼 보입니다.

SemVer에는 "대부분 중요하지 않은 세부 사항"예외가 있다고 생각하지 않습니다.

해결되지 않은 질문 목록에 종료 코드를 추가해야 한다고 생각합니다. @zackw 는 관련 내부 스레드 도 열었습니다.

많은 사람들은 실패 시 종료 코드가 1 여야 한다는 데 동의합니다( 2 대신).
https://www.reddit.com/r/rust/comments/6nxg6t/the_rfc_using_in_main_just_got_merged/

@arielb1 이 RFC를 구현하시겠습니까?

@bkchr

아니, 단지 그것을 멘토링하기 위해. 멘토링 노트를 작성하는 것을 잊지 않기 위해 할당했습니다.

아, 좋아요, 관심을 가지고 해보고 싶어요 :)
하지만 어디서부터 시작해야 할지 모르겠습니다. :D

@bkchr

그래서 내가 여기에 있습니다 :-). 조만간 멘토링 지침을 작성해야합니다.

좋아요, 그럼 저는 당신의 지시를 기다리고 있습니다.

멘토링 지침

[WG-컴파일러-중간] 문제입니다. 도움이 필요하시면 irc.mozilla.org(저는 arielby입니다) 또는 https://gitter.im/rust-impl-period/WG-compiler-middle (저는 @arielb1 입니다)에서 #rustc에 가입할 수 있습니다. 거기).

WIP 컴파일러 readme는 #44505에 있습니다. 컴파일러의 몇 가지 사항을 설명합니다.

이 RFC에 대한 작업 계획:

• [ ] - Termination lang-item을 libcore에 추가
• [ ] - main Termination 사용 허용
• [ ] - doctest에서 Termination 사용 허용
• [ ] - #[test] Termination 사용 허용

Termination lang-item을 libcore에 추가

먼저 Termination 특성을 libcore/ops/termination.rs 에 몇 가지 문서와 함께 추가해야 합니다. 또한 #[unstable(feature = "termination_trait", issue = "0")] 속성을 사용하여 불안정한 것으로 표시해야 합니다. 이렇게 하면 안정화되기 전에 사람들이 사용하지 못하게 됩니다.

그런 다음 src/librustc/middle/lang_items.rs 에 lang-item 으로 표시해야 합니다. 이것은 컴파일러가 main 유형을 검사할 때 이를 찾을 수 있음을 의미합니다(예: 0c3ac648f85cca1e8dd89dfff727a422bc1897a6 참조).
그것의 의미는:

1. lang-items 목록에 추가하기 ( in librustc/middle/lang_items.rs )
2. Termination 트레잇에 #[cfg_attr(not(stage0), lang = "termination")] 추가. #[lang = "termination"] 속성을 추가할 수 없는 이유는 "stage0" 컴파일러(부트스트래핑 중)가 termination 가 존재한다는 사실을 알지 못하기 때문에 libstd를 컴파일합니다. stage0 컴파일러를 업데이트할 때 cfg_attr 를 수동으로 제거합니다.
   자세한 내용은 XXX에서 부트스트랩 문서를 참조하세요.

메인에서 Termination 사용 허용

이것은 내가 처리하는 방법을 알고 있는 흥미로운 부분입니다. 이것은 $ () main 를 만드는 것을 의미합니다(현재 main function has wrong type 오류가 발생함) 및 작동합니다.

유형 검사를 하려면 먼저 다음에서 기존 오류를 제거해야 합니다.
https://github.com/rust-lang/rust/blob/9a00f3cc306f2f79bfbd54f1986d8ca7a74f6661/src/librustc_typeck/lib.rs#L171 -L218

그런 다음 반환 유형이 Termination 트레잇을 구현하는지 확인을 추가해야 합니다( register_predicate_obligation 를 사용하여 트레잇 의무를 추가 - 해당 용도 검색). 여기에서 할 수 있습니다.
https://github.com/rust-lang/rust/blob/9a00f3cc306f2f79bfbd54f1986d8ca7a74f6661/src/librustc_typeck/check/mod.rs#L1100 -L1108

다른 부분은 그것을 작동시키는 것입니다. 그것은 오히려 쉬워야합니다. RFC에서 말했듯이 lang_start 를 반환 유형에 대해 일반화하려고 합니다.

lang_start 는 현재 여기에 정의되어 있습니다.
https://github.com/rust-lang/rust/blob/9a00f3cc306f2f79bfbd54f1986d8ca7a74f6661/src/libstd/rt.rs#L32

따라서 일반으로 변경하고 RFC와 일치해야 합니다.

#[lang = "start"]
fn lang_start<T: Termination>
    (main: fn() -> T, argc: isize, argv: *const *const u8) -> !
{
    use panic;
    use sys;
    use sys_common;
    use sys_common::thread_info;
    use thread::Thread;

    sys::init();

    sys::process::exit(unsafe {
        let main_guard = sys::thread::guard::init();
        sys::stack_overflow::init();

        // Next, set up the current Thread with the guard information we just
        // created. Note that this isn't necessary in general for new threads,
        // but we just do this to name the main thread and to give it correct
        // info about the stack bounds.
        let thread = Thread::new(Some("main".to_owned()));
        thread_info::set(main_guard, thread);

        // Store our args if necessary in a squirreled away location
        sys::args::init(argc, argv);

        // Let's run some code!
        let exitcode = panic::catch_unwind(|| main().report())
            .unwrap_or(101);

        sys_common::cleanup();
        exitcode
    });
}

그런 다음 create_entry_fn 에서 호출해야 합니다. 현재 lang_start Instance::mono 를 사용하여 단형 lang_start 을 인스턴스화하고 올바른 부분과 함께 monomorphize::resolve 를 사용하도록 변경해야 합니다.

https://github.com/rust-lang/rust/blob/9a00f3cc306f2f79bfbd54f1986d8ca7a74f6661/src/librustc_trans/base.rs#L697

doctest에서 Termination 사용 허용

나는 doctest가 어떻게 작동하는지 정말로 이해하지 못한다. @alexcrichton 에게 물어봐도 될까요?

#[test] Termination 사용 허용

나는 libtest가 어떻게 작동하는지 정말로 이해하지 못합니다. @alexcrichton 에게 물어봐도 될까요? 단위 테스트는 기본적으로 매크로에 의해 생성되므로 () 가 아닌 반환 유형을 처리하려면 해당 매크로 또는 호출자를 변경해야 합니다.

@bkchr

최소한 IRC/gitter에 가입할 수 있습니까?

@bkchr 방금 체크인 -- 당신과 @arielb1 이 얼마 전에 gitter에 대해 대화하는 것을 보았는데, 진전이 있었습니까? 어딘가에 빨려?

죄송합니다. 현재까지 진행 상황이 없습니다. 현재 할 일이 많지만 이번 주에 시간을 내서 시작할 수 있기를 바랍니다.

@bkchr 도움이 필요하시면 알려주세요!

나는 현재 약간 붙어 있습니다. 의무를 만들고 싶습니다. 의무를 생성하려면 TraifRef가 필요하고 TraitRef의 경우 DefId가 필요합니다. 누군가가 Termination Trait에서 DefId를 생성하는 방법에 대한 코드를 알려줄 수 있습니까?

@bkchr 특성은 lang 항목 목록에 추가되어야 합니다. 예: https://github.com/rust-lang/rust/blob/ade0b01ebf18550e41d24c6e36f91afaccd7f389/src/librustc/middle/lang_items.rs#L312
#[termination_trait] 로 표시됩니다. 예: https://github.com/rust-lang/rust/blob/ade0b01ebf18550e41d24c6e36f91afaccd7f389/src/libcore/fmt/mod.rs#L525 -L526

네, 그게 문제가 아닙니다. 이미 그렇게 했습니다. check_fn 함수에서 종료 특성을 확인해야 합니다. 나는 register_predicate_obligation을 사용하고 싶고 이를 위해서는 종료 특성의 정의가 필요합니다.

오, 그러면 tcx.require_lang_item(TerminationTraitLangItem) 있으면 됩니다.

@bkchr 어때요 ? 다시 체크인만 하면 됩니다. =) 바쁘더라도 걱정하지 마세요. 필요한 모든 도움을 받고 있는지 확인하고 싶을 뿐입니다.

죄송합니다, 지금은 바쁘네요 :/ 지금까지 필요한 모든 도움을 받았습니다 :)

이것은 TerminationTrait를 확인하는 코드입니다. https://github.com/bkchr/rust/blob/f185e355d8970c3350269ddbc6dfe3b8f678dc44/src/librustc_typeck/check/mod.rs#L1108

함수의 반환 유형을 확인하지 않는 것 같아요? 다음 오류가 발생합니다.

error[E0277]: the trait bound `Self: std::ops::Termination` is not satisfied
  --> src/rustc/rustc.rs:15:11
   |
15 | fn main() { rustc_driver::main() }
   |           ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::ops::Termination` is not implemented for `Self`
   |
   = help: consider adding a `where Self: std::ops::Termination` bound

함수의 반환 유형을 확인하려면 무엇을 변경해야 합니까?

@bkchr 피드백을 위해 https://gitter.im/rust-impl-period/WG-compiler-middle에서 컴파일러 중간 작업 그룹 gitter에 참여하고 https에서 #rust-internals IRC 채널을 시도하는 것이 좋습니다. //chat.mibbit.com/?server=irc.mozilla.org%3A%2B6697&channel=%23rust-internals . :)

@bstrie 예 감사합니다. 저는 이미 gitter 채팅에 참여했으며 문제를 해결할 수 있습니다. :)

@bkchr 귀하의 문제는 이 줄에 있습니다. 빌드하려는 트레잇 참조는 R: Termination 와 같은 것입니다. 여기서 R 는 함수의 반환 유형입니다. 이것은 특성의 유형 매개변수(이 경우 Self )를 대체할 값 세트인 적절한 "substs"를 구축하여 지정됩니다.

그러나 트레이트에서 Substs::identity_for_item 메서드를 호출하고 있습니다. 이렇게 하면 특성 정의 자체 내에서 사용할 대체 항목을 다시 얻을 수 있습니다. 즉, 이 경우 Termination 트레잇에 선언된 Self 매개변수를 Self 에 매핑합니다. Terminator 트레잇 내에서 일부 함수의 정의를 확인하는 경우에는 적절하지만 여기서는 그다지 많지 않습니다.

대신 원하는 것은 입력 함수의 반환 유형을 얻는 것입니다. 이것은 ret_ty 또는 actual_ret_ty 변수 중 하나일 뿐입니다. 어느 쪽이든 괜찮지만 ret_ty 가 더 나은 것 같습니다. 이는 사용자 가 선언 한 반환 유형에 해당합니다(반면 actual_ret_ty 는 실제 코드 반환 유형).

tcx에서 mk_substs() 메소드를 호출하기만 하면 원하는 서브스트를 만들 수 있습니다. 이 경우에는 type이라는 매개변수가 하나만 있으므로 let substs = fcx.tcx.mk_substs(&[ret_ty]); 와 같은 것이 작동할 것이라고 생각합니다.

나는 사용할 것이 tcx.mk_substs_trait(ret_ty, &[]) 라고 생각합니다.

@bkchr 방금 체크인 -- 그 조언을 사용할 기회가 있었나요? (또한 빠른 응답 을 위해서는 gitter에 문의하는 것이 현명할 수 있습니다.)

예, gitter로 문제를 해결할 수 있습니다 :)

@bkchr 어때요 ? 체크인만 하면 됩니다.

괜찮습니다. 이번 주에 코드를 살펴볼 시간이 있을 것입니다.

이 일을 도와줄 사람이 한 명 더 있습니까? 저는 올해가 끝나기 전에 Rust 커뮤니티에 기여하기 시작하고 이 기능을 돕고 싶습니다. 두 사람이 함께 작업하는 것이 너무 혼란스럽지 않기를 바랍니다.

@U007D

이것은 작은 기능이며 @bkchr 이 거의 완료되었습니다.

아, 알겠습니다. 감사합니다. 내가 도울 수 있는 다른 일을 계속 주시하겠습니다.

@U007D https://www.rustaceans.org/findwork 보셨나요?

@lnicola 네, 있습니다! 나는 일할 수 있다고 확신하는 것(즉, 긍정적인 사람이 되는 것)과 열정적인 것의 교차점에서 무언가를 찾으려고 노력하고 있습니다. 솔직히 말해서 Rust를 배운 지 1년 정도 됐지만, 자원봉사를 하기 위해 나서는 것은 여전히 ​​조금 겁이 납니다. FWIW, 그것은 결코 Rust 커뮤니티의 잘못이 아닙니다. Rust 커뮤니티는 이것을 개방적이고 환영하며 포용적인 문화로 만들기 위해 뒤로 구부렸습니다. 내가 경험한 최고의 즐거움입니다. (나는 팀이 협업보다 경쟁적인 경향이 있는 기술 산업에서 수년간의 경험에서 비롯된 오래된 전투 흉터와 더 관련이 있다고 생각합니다.)

어쨌든 올해는 무언가를 골라 적어도 긍정적인 기여를 하는 것이 제 목표입니다. 내가 참여할 시간이야! :)

제안 감사합니다, @lnicola. 좋은 자료입니다.

@bkchr 업데이트가 있습니까?

나는 그것에 있습니다 (https://github.com/rust-lang/rust/pull/46479). 이제 풀 리퀘스트의 댓글에서 작업할 휴일과 시간이 있습니다. 모든 지연에 대해 죄송합니다 :/

오, 죄송합니다. 풀 리퀘스트가 있다는 것을 몰랐습니다. 교차 연결했습니다.

안녕하세요, 음. 그래서 저는 제 잠재적인 Rust 기여자 경력을 전통과 마찬가지로 자전거를 탈 때 시작하겠다고 생각했습니다. 구체적으로, 이것에 대해:

• [ ] 도입되는 특성의 이름

Exit 는 어떻습니까? 기존의 Rust 어휘에 맞는 짧고 요점입니다. 명사 출구는 "내부에서" 프로세스를 통제된 방식으로 끝내는 데 익숙한 동사인 exit as a 동사의 자연스러운 대응물입니다.

특히 C++ 프로그래머에게 "종료"는 기본적으로 비정상적인 종료( abort 호출)로 설정되는 std::terminate 를 떠올리게 하며 기본적으로 C++는 패닉에 해당합니다(그러나 패닉과 달리 스택).

잠깐, 그 의견을 무시하십시오. RFC가 토론에 명시적으로 열려 있는 것처럼 보입니다.

나는 Exit 를 특성 이름으로 좋아합니다.

Carrier 에서와 같이 특성이 안정화되기 훨씬 전에 기능이 안정화될 것이라고 생각하고 있습니다.

FWIW 안정화 전에 임시 이름이 변경된 것이 정말 다행인 또 다른 경우입니다 :D

RFC의 작성자로서 나는 특성의 이름을 Exit 또는 다른 어떤 것으로 변경하는 데 이의가 없습니다. 나는 특별히 이름을 짓는 것을 잘하지 못하며 다른 사람이 더 나은 아이디어를 갖게 되어 기쁩니다.

https://github.com/rust-lang/rust/blob/5f7aeaf6e2b90e247a2d194d7bc0b642b287fc16/src/libstd/lib.rs#L507

특성이라고 해야하나

1. libcore 대신 libstd에 배치하고
2. std::ops::Termination 가 아니라 std::Termination #$ ?

Result stderr 인쇄해야 하고 libcore 에서 수행할 수 없기 때문에 트레이트를 libcore 에 배치할 수 없습니다.

@bkchr impl이 libstd에 있다는 것이 특성이 libstd에도 있어야 한다는 의미는 아닙니다.

@kennytm 알지만 Result도 libcore에 정의되어 있으므로 libstd의 Result에 대해 Termination을 구현할 수 없습니다.

@zackw 특성 이름으로 Exit 에 대해 +1 투표

@U007D : 이런 글 대신 리액션 버튼(예: 👍)을 눌러주실 수 있나요? 그렇게 하면 불필요하게 핑을 보내 성가신 문제 가입자를 피할 수 있습니다.

language_feature 가 활성화된 경우 libtest / libsyntax 를 체크인할 수 있습니까(상자에서)? @arielb1 @nikomatsakis @alexcrichton

libsyntax 의 @bkchr을 전달해야 할 수도 있지만 이론적으로는 가능하지만 런타임에 libtest 자체에서는 확인할 수 있다고 생각하지 않습니다.

@bkchr 여기 어떻게 가나요?

아직 작업 중이지만 현재 더 이상 질문이 없습니다. :)

이 impl은 너무 엄격하다고 생각합니다.

#[unstable(feature = "termination_trait", issue = "43301")]
impl<T: Termination, E: Error> Termination for Result<T, E> {
    fn report(self) -> i32 {
        match self {
            Ok(val) => val.report(),
            Err(err) => {
                print_error(err);
                exit::FAILURE
            }
        }
    }
}


#[unstable(feature = "termination_trait", issue = "43301")]
fn print_error<E: Error>(err: E) {
    eprintln!("Error: {}", err.description());

    if let Some(ref err) = err.cause() {
        eprintln!("Caused by: {}", err.description());
    }
}

Error , 가장 중요한 것은 Box<::std::error::Error> 및 failure::Error 를 구현하지 않는 몇 가지 일반적으로 사용되는 오류가 있습니다. 또한 이 오류의 표시 impl 대신 description 메서드를 사용하는 것도 실수라고 생각합니다.

이 impl을 더 넓은 impl로 교체할 것을 제안합니다.

#[unstable(feature = "termination_trait", issue = "43301")]
impl<T: Termination, E: Display> Termination for Result<T, E> {
    fn report(self) -> i32 {
        match self {
            Ok(val) => val.report(),
            Err(err) => {
                eprintln!("Error: {}", err)
                exit::FAILURE
            }
        }
    }
}

그것은 불행한 원인 사슬을 잃습니다.

설명보다 디스플레이 암시를 사용하는 것이 확실히 더 나은 방법입니다.

원인 사슬은 흥미로운 문제입니다. 특히 이 구현은 원인 사슬의 처음 두 구성원만 인쇄합니다.

실패는 원인 사슬을 처리하는 방법을 다루어야 했고 기본적으로 이 동작을 해결해야 했습니다(예: .context 를 사용하여 오류를 빌드하는 경우:

• {} 는 이 오류만 인쇄합니다.
• {:?} 는 이 오류와 그 원인을 인쇄합니다(재귀적으로).

여기서 :? 를 사용하기로 결정하고 Display 대신 Debug를 바인딩할 수 있습니다. 불안정한.

예, 지원하려면 impl을 개선해야 한다는 것을 이미 알고 있습니다. 나는 우리가 무엇을 할 수 있는지 열려 있습니다. Debug 에 바인딩하는 것이 좋습니다.

흠, 이것은 까다로운 것입니다. 우리가 "세련된" 프로그램이 이 특성 impl을 사용할 것이라고 생각하는지 여부에 달려 있다고 생각합니다. 나는 "아니요, 그들은 그렇지 않을 것입니다"라고 말하는 것이 괜찮다고 생각하는 경향이 있습니다. 기본적으로 세련된 프로그램은 (a) 출력을 포착하여 다른 방식으로 처리하거나 (b) 일부 newtype 또는 디버그를 구현하는 것을 사용합니다. 옳은 길. 이것은 유용한 정보를 덤핑하기 위해 impl을 최적화할 수 있지만 반드시 가장 예쁜 형태( Debug 의 역할처럼 보임)로 최적화할 수 있음을 의미합니다.

대부분의 프로덕션 사용 사례에 올바른 방식으로 오류를 자동으로 처리할 수 없다고 생각하기 때문에 Debug 를 사용하여 프로토타입을 매우 명확하게 대상으로 지정하는 것이 올바른 선택일 수 있습니다.

@withoutboats 동의합니다.

@nikomatsakis "반드시 가장 예쁜 형태는 아니다 "라고 말씀하신 것 같은데요? 그렇다면 예, 동의합니다.

업데이트: 며칠 동안 이 작업을 수행한 후 전환했습니다. 아래를 참조하십시오.

:+1: Debug , 여기; 나는 https://github.com/rust-lang/rfcs/pull/1937#issuecomment -284509933에서 @nikomatsakis 의 "잡히지 않은 예외와 유사한 종류"를 좋아합니다. Debug 를 제안하는 Diggsey의 의견: https://github.com/rust-lang/rfcs/pull/1937#issuecomment -289248751

참고로 저는 "더 완성도 높은" 대 "더 사용자 친화적인" 기본값(예: Debug 대 Display 특성 경계) 문제에 대해 설명했습니다.

TL;DR은 이제 경계를 Display 로 설정하여 '아무것도 하지 않는' 경우에 더 깔끔하고 요약 된 출력을 제공해야 한다고 생각합니다.

내 근거는 다음과 같습니다.

termination 트레잇의 RFC 문제 에서 @zackw 는 Rust가 이중 panic / Result 시스템을 가지고 있다는 점을 강조합니다. 왜냐하면 panic 는 버그를 위한 것이고 Result 은

물론 모든 사람을 만족시키는 기본값은 없으므로 최소한의 놀라움의 원칙을 적용하여 어떤 기본값이 더 적절한지 자문해 봅니다.

• 오류는 종종 (고칠 수 있는) 문제(파일을 찾을 수 없음 등)가 잘못되었음을 사용자에게 알리기 위한 것이라는 점에서 설계에 의해 처리되지 않습니다. 따라서 사용 사례가 존재하고 사용자가 의도한 청중이라는 합리적으로 일반적으로 간주될 수 있습니다.

• @nikomatsakis 가 지적했듯이 우리가 선택한 기본값에 관계없이 동작을 변경하려는 개발자는 newtype 패턴을 사용하거나 main()에서 사용자 정의 구현을 개발할 수 있습니다.

그리고 마지막으로 더 주관적인 측면에서, 지난 며칠 동안 이 기능을 사용하면서 Debug 출력이 내 "Rust 앱"이 더 세련되지 않은 느낌을 주는 것을 발견했습니다.

$ foo
Error: Custom { kind: Other, error: StringError("returned Box<Error> from main()") }
$

대

$ foo
Error: returned Box<Error> from main()
$

Dispay 트레잇은 (버그와 반대되는) 오류에 대한 훨씬 더 문명화된 기본값인 것 같습니다. 그렇지 않습니까?

@U007D 잠깐, 이 두 가지 출력 중 어떤 것을 선호하시나요?

(a) Error: Custom { kind: Other, error: StringError("returned Box<Error> from main()") }

또는

(b) Error: returned Box<Error> from main()

그는 옵션 (b)를 선호합니다.

@nikomatsakis 원래, 나는 a) Debug 를 내 머리 속의 개념으로 괜찮았지만 실제로 며칠 동안 작업한 후에 실제로 출력을 보고 b) Display 를 선호했습니다. 기본값. 연쇄 오류를 모델링하는 경우 b)에 대한 선호도가 훨씬 더 뚜렷해질 것이라고 생각합니다.

"광택"이나 "문명화"가 이것의 목표라고 생각하지 않습니다. 스레드가 이미 이것을 대부분 예제용으로 받아들이고 프로그램이 성숙해짐에 따라 사용자 정의 처리를 추가할 것으로 완전히 예상되는 스레드를 이해했기 때문입니다.

그런 경우 나에게 "최소한의 놀라움"은 unwrap 와 같은 개발자 지향 출력입니다.

긴 오류에 대한 우려가 있는 경우 여기에서 {:#?} 에 대해 논의할 가치가 있습니까?

최종 사용자를 위한 오류 보고는 모든 도구와 모든 사용 사례에 따라 다르지만 개발자를 위한 오류 보고는 Rust가 .unwrap() 와 같은 다른 상황에서 하는 것과 유사해야 합니다. 기본값은 하나만 있을 수 있고 세련된 소프트웨어는 어쨌든 출력을 재정의해야 하므로 Debug 가 있는 개발자 중심의 기본값에 투표합니다.

이 토론의 핵심은 정말 "기본 메시지의 대상 독자는 누구입니까?"라고 생각합니다.

잠시 동안 우리 모두가 기본 대상이 개발자라는 데 동의했다고 가정해 보겠습니다. Debug 기본 바운드가 간단한 선택이라고 생각합니다.

이제 기본 대상 청중이 사용자라는 데 동의했다고 잠시 가정해 보겠습니다. 그리고 여기에서 저는 특히 다른 사람들과 동의하지 않으며 "세련된" 및 "문명화된" 출력과 같은 주관적인 특성이 중요한 역할을 한다고 생각합니다. 플레이. 어떤 사람들에게는 최종 사용자 프리젠테이션 "광택"이 Display 를 피하는 가장 좋은 이유일 수 있습니다. (나는 그 견해를 공유하지 않지만 그것을 이해하고 존중합니다.)

예, 두 그룹에 대한 합리적인 인수를 기본 대상으로 확실히 볼 수 있습니다. 내 생각에 어떤 청중이 기본 대상이어야 하는지에 대한 강력한 합의가 이루어지면 특성 경계에 대한 선택이 명확해질 것입니다(어)... :)

(나는 이 전체 주제에 정통하지 않지만) Termination 가 포함된 기본 오류 출력이 사용자가 표시할 수 있는 형식이라면 완벽하게 적절한 작은 유틸리티가 있을 수 있다는 것은 상상할 수 없습니다. Display 처럼? 이 경우 작성자가 "맞춤 처리"에 도달해야 하는 유일한 이유는 우리가 만들 수 있기 때문입니다.

누군가 각 경우에 출력이 어떻게 보이는지에 대한 예를 제공할 수 있습니까(사용된 특정 E 유형에 따라 다르다고 가정하고 있습니까?), 그리고 작성자가 "사용자 정의 처리"를 원할 경우 실제로 취해야 하는 단계는 무엇입니까? 대신에? 나는 단지 위의 가정을 할 것입니다.

(출력이 문자 그대로 위에 @U007D를 붙여넣은 것과 같습니까? "반환된 Box\"가 인쇄되는 이유는 무엇입니까?상자<오류>?)

오류 메시지의 Display 가 얼마나 자주 사용자에게 친숙합니까? 예를 들어 다음 프로그램:

fn main() {
    if let Err(e) = std::fs::File::open("foo") {
        println!("{}", e)
    }
}

다음 메시지를 내보냅니다.

No such file or directory (os error 2)

특히 파일 이름이 언급되지 않은 경우에는 훌륭한 UX가 아닙니다. 적어도 프로그램이 문자 그대로 단일 파일 이름을 입력으로 사용하지 않는 한 그렇지 않습니다. 반면에 소스 파일/라인 번호/스택 추적이 누락되어 개발자 경험도 좋지 않습니다. Debug 출력은 분명히 훨씬 더 나쁜 사용자 경험이며 감속기에게도 유용한 정보를 추가하지 않습니다.

그래서 내가 말하려는 것은 라이브러리 오류 자체의 정보 내용을 개선하지 않고는 Debug 도 Display 도 좋지 않다는 것입니다.

출력이 문자 그대로 위에 @U007D를 붙여넣은 것과 같습니까? 왜 "returned Boxfrom main()" 대신... 해당 상자의 실제 내용?

@glaebhoerl 당신이 맞습니다. 이 경우 " Box<Error> 의 실제 내용"은 termination_trait 를 테스트하기 위해 만든 사용자 정의 message 필드 였습니다 . . 대신에 "foo bar baz" 또는 다른 것을 작성할 수 있었습니다(그러나 컴파일러 테스트를 실행하는 사용자에게는 유용하지 않았을 수 있음).

@jdahlstrom 의 예를 사용하여 다음은 Box ed 표준 라이브러리 "file not found" Error 에 대한 실제 출력입니다(참고로, 올바르게 지적했듯이 권투에 대한 언급은 어디에도 없음).
Debug :

$ foo
Error { repr: Os { code: 2, message: "No such file or directory" } }
$

및 Display :

$ foo
No such file or directory (os error 2)
$

@jdahlstrom 좋은 지적을 하신 것 같아요. 두 메시지 모두 대상 고객에게 제대로 서비스를 제공하지 못할 수 있다는 점에 동의하며 잘못된 메시지를 제공하는 것이 훨씬 더 나쁘다는 점을 강조하고 싶습니다(당신이 언급한 것처럼).

Display 를 개발자에게 제공하는 것은 Debug 의 모든 단점 과 함께 표시되는 오류 유형의 특정성을 놓치는 것입니다.

Debug 를 사용자 에게 제공하면 Display 의 모든 단점이 있을 뿐만 아니라 사용자가 필요로 하지 않고 이해할 수 없는 기술 정보가 더 추가 됩니다.

예, 메시지가 두 청중 모두에게 충분히 타겟팅되지 않는 경우가 많다는 데 동의합니다. 이것은 우리가 목표로 삼고 있는 사람을 명확히 하여 그 그룹에 대해 우리가 할 수 있는 최고의 경험(결점에도 불구하고)을 제공해야 하는 또 다른 중요한 이유라고 생각합니다.

#[test] ? 에 대한 지원을 구현하는 데 도움이 필요합니다. 내 현재 구현은 여기에서 찾을 수 있습니다: https://github.com/rust-lang/rust/compare/master...bkchr :termination_trait_in_tests

내 변경 사항으로 테스트를 컴파일하면 다음 오류가 발생합니다.

error: use of unstable library feature 'test' (see issue #27812)
  |
  = help: add #![feature(test)] to the crate attributes to enable

@eddyb 는 quote_item!/expr! 가 레거시이기 때문에 더 이상 사용하지 말아야 한다고 말했습니다.
이제 무엇을 해야 합니까, 새로운 quote! 매크로로 전환하거나 모든 것을 수동 ast 건물로 재작업해야 합니까?

나는 어떤 도움을 주셔서 감사합니다 :)

libtest 에 정의된 일부 매크로에 대한 매크로 호출을 생성하는 것은 매우 잘 작동할 수 있다고 생각합니다.

@eddyb 여기에서 귀하의 제안을 이해했는지 잘 모르겠습니다.

libtest에 정의된 일부 매크로에 대한 매크로 호출을 생성하는 것이 매우 잘 작동할 수 있다고 생각합니다.

오, 아마 할 것 같아요. libtest에서 매크로를 정의한 다음 이를 호출하는 코드를 생성한다는 말씀이신가요? 흥미로운 아이디어입니다. 그 매크로 이름이 일종의 "누출"이 되지 않습니까? (즉, libtest의 공용 인터페이스의 일부가 됩니까?)

@bkchr

내 변경 사항으로 테스트를 컴파일하면 다음 오류가 발생합니다.

해당 오류가 생성되는 이유를 알고 있습니까? diff를 읽는 것만으로는 그렇지 않지만 로컬에서 빌드하고 알아낼 수 있습니다.

quote_item!/expr! 는 더 이상 사용하면 안 됩니다. 레거시이기 때문입니다.

나는 여기에 강한 의견이 없습니다. @eddyb 에 동의합니다. 레거시지만 몇 가지 용도를 더 추가하면 제거하기가 더 어려워지는 일종의 레거시인지 확실하지 않습니다. 즉, 최근에 교체하면 쉬울까요? @eddyb 에서 다른 곳으로 이동하시겠습니까?

수동 AST 구축은 확실히 고통스럽습니다. 하지만 이를 위한 도우미가 있다고 생각합니다.

대부분 약간만 수정하면 됩니다. 그렇죠? 즉, 함수 호출에서 report() 결과 테스트로 변경?

추신, 우리는 Termination 트레잇이 범위에 있는 것을 피하기 위해 .report() 표기법을 사용하는 대신 Termination::report(...) 와 같은 것을 생성하기를 원할 것입니다.

아니요, 그 오류가 어디에서 왔는지 전혀 모릅니다 :(

RFC는 원래 테스트 함수를 호출하는 래퍼 함수를 ​​생성하도록 제안했습니다. 그것이 현재 나의 방법이기도 하다.
래퍼 함수를 ​​삭제할 수도 있지만 각 테스트 함수가 다른 유형을 반환할 수 있으므로 함수 포인터를 박싱해야 한다고 생각합니다.

흠, 테스트는 이미 다른 것을 가져오기 때문에 Termination 트레잇을 가져오는 것도 그렇게 복잡하지 않습니다.

@alexcrichton 이 오류의 출처가 어디인지 알고 있습니까?

@nikomatsakis libtest 불안정하고 매크로도 불안정하다고 표시할 수 없나요?

@eddyb 오, 좋은 지적입니다.

RFC는 원래 테스트 함수를 호출하는 래퍼 함수를 ​​생성하도록 제안했습니다. 그것이 현재 나의 방법이기도 하다.

래퍼 기능이 괜찮은 것 같습니다.

@eddyb 매크로를 사용하면 libtest create_test 와 같은 것을 의미합니까? 그러나 내가 이해하지 못하는 것은 "매크로를 불안정한 것으로 표시"입니다. 그걸로 뭘 하려는 겁니까? 예를 들어주시겠습니까?

@bkchr 매크로 정의에 #[unstable(...)] 속성 추가, 예: https://github.com/rust-lang/rust/blob/3a39b2aa5a68dd07aacab2106db3927f666a485a/src/libstd/thread/local.rs#L159

따라서 이 첫 번째 확인란을 선택해야 합니까?

RFC 구현

...연결된 PR이 병합되었는지 확인하시겠습니까?

@ErichDonGubler 완료 :)

흠, 현재 병합된 pr로 구현되는 것은 절반의 rfc뿐입니다 ^^

3개의 체크박스로 구분됩니다 :)

main 에서 이 기능을 사용하려고 시도했지만 꽤 실망스러웠습니다. 종료 특성의 기존 impls는 여러 종류의 오류를 편리하게 "누적"하는 것을 허용하지 않습니다. 예를 들어 Error 를 구현하지 않기 때문에 failure::Fail 를 사용할 수 없습니다. Error ; 같은 이유로 Box<Error> 사용할 수 없습니다. Debug 로 변경하는 것을 우선시해야 한다고 생각합니다. =)

안녕하세요, @nikomatsakis ,

termination_trait 를 사용하려고 할 때와 똑같은 좌절감을 느꼈습니다.

그것은 컴파일러 해킹에 대한 귀하의 게시물과 결합하여 이번 달 초에 이 문제를 해결하도록 영감을 주었습니다. https://github.com/rust-lang/rust/pull/47544 에 테스트와 함께 Display (및 이전 커밋의 Debug )에 대한 impl을 게시했습니다. (아주 사소하지만 여전히 내 첫 번째 Rust 컴파일러 PR입니다! :tada:) :)

내 이해는 lang 팀이 어떤 특성을 사용할 것인지에 대해 전화를 걸 것이지만 어느 쪽이든 구현 준비가 되었다는 것입니다.

여전히 관심이 있는 질문: 기본 오류 메시지 출력( Debug 또는 Display )에 의존하고 싶지 않고 대신 자신만의 오류 메시지를 원한다고 가정해 보겠습니다. 어떻게 합니까? 저것? (이미 어딘가에 적어두어서 놓쳤다면 죄송합니다.) ? -in- main 사용을 완전히 중단할 필요는 없겠죠? 자신의 결과 및/또는 오류 유형 및/또는 impl 를 작성하는 것과 같습니다. ( ? -in- main 가 장난감에 불과 하고 "진지하게" 하고 싶다면 인체공학적이지 않은 방식으로 돌아가야 한다는 것이 나에게는 불행한 일인 것 같습니다.)

@glaebhoerl 매우 간단합니다.

1. 새 유형을 만듭니다.
2. From 이전 오류 유형을 구현하십시오.
3. Debug (또는 Display )를 구현합니다.
4. main 의 서명에서 유형을 바꿉니다.

감사 해요!

디버깅 지향적 이지 않은 Debug 의 사용자 정의 구현을 작성하는 것이 약간 이상해 보이지만 이것이 세상의 끝은 아닌 것 같습니다.

@glaebhoerl 이것이 Result impl이 Debug Display 를 사용해야 하는 이유입니다.

Termination 트레잇에 message 또는 error_message 또는 이와 유사한 추가 메소드가 있을 수 없으며 Debug / Display 메시지를 표시하시겠습니까? 그런 다음 새 유형을 만드는 대신 단일 메서드를 구현하기만 하면 됩니다.

@glaebhoerl @Thomasdezeeuw error_message 방법과 같은 것이 RFC의 원래 초안에 있었지만 합의가 부족하여 삭제되었습니다. 당시의 내 느낌은 기본 기능을 확보하고(반드시 안정화될 필요는 없음) 반복하는 것이 가장 좋다는 것이었습니다.

@zackw 동의합니다. 개인적으로 메시지 없이 숫자만 있으면 괜찮습니다. 오류 코드에 대해 0 및 1 라고 합시다. 그러나 첫 번째 반복에서 메시지를 받고 싶다면 Debug 또는 Display Termination::message 를 더 선호할 것입니다.

message 메서드가 String 를 반환할까요? Termination 가 libcore에 있는 것과 호환되지 않습니까?

@SimonSapin Termination 는 현재 libstd 에 정의되어 있습니다.

흠, 하지만 트레잇에 message 메소드를 추가하는 것이 최선의 구현이 될 것이라고는 생각하지 않습니다. i32 와 같은 유형에 대해 메서드는 무엇을 반환합니까? 이 메시지를 인쇄할 시기를 어떻게 결정합니까? 현재 Result Termination report 함수에 오류를 인쇄합니다. Result 가 Err 임을 알기 때문에 작동합니다. report() != 0 수표를 어딘가에 통합한 다음 인쇄할 수 있지만 그것은 옳지 않습니다.
다음 문제는 Result 에 대한 표준 구현을 제공하고 싶지만 Error 유형이 인쇄하기 위해 구현해야 하는 것은 무엇입니까? 이렇게 하면 현재 질문 Debug 또는 Display 로 돌아갑니다.

"심각한" 프로그램의 main에서 ? 를 사용하려는 경우 발생하는 또 다른 골칫거리는 일부 상황에서 명령줄 프로그램이 0이 아닌 상태로 종료되기를 원하지만 _아무것도_ 인쇄하지 않으려는 것입니다( grep -q 고려 Error 가 _아닌_ 어떤 것에 대한 Termination impl 이 필요합니다. 아무 것도 인쇄하지 않고 종료 상태를 제어할 수 있습니다. 명령줄 인수를 구문 분석한 _after_ 그 물건을 다시 반환합니다.

이것은 내가 생각하는 것입니다 :

Result<T, E> 를 반환하는 것은 E에 디버그 impl을 사용해야 합니다. 이것은 가장 편리한 특성입니다. 이것은 널리 구현되고 "빠르고 더러운 출력" 사용 사례와 단위 테스트 사용 사례를 충족합니다. 저는 Display 를 사용하지 않는 것을 선호합니다. 왜냐하면 덜 널리 구현 되고 이것이 세련된 출력이라는 인상을 주기 때문입니다. 그럴 가능성은 거의 없습니다.

그러나 전문적인 결과물을 얻을 수 있는 방법도 있어야 합니다. 다행히도 이미 두 가지 방법이 있습니다. 첫째, @withoutboats 가 말했듯이 사람들은 E: Display 를 사용하거나 전문적인 스타일의 출력을 제공하려는 경우 "디버그에서 표시" 브리지를 만들 수 있습니다. 그러나 이것이 너무 해킹된 것처럼 느껴진다면 결과를 대체하기 위해 고유한 유형을 정의할 수도 있습니다. 예를 들어 다음을 수행할 수 있습니다.

fn main() -> ProfessionalLookingResult {
    ...
}

그런 다음 ProfessionalLookingResult Try 를 구현합니다. 그런 다음 Terminate 도 구현할 수 있습니다.

impl Terminate for ProfessionalLookingResult {
    fn report(self) -> i32 {
        ...
        eprintln!("Something very professional here.");
        return 1;
        ...
    }
}

Debug 을 사용해야 한다는 @nikomatsakis 의 의견에 동의합니다.

또한 세련된 출력의 경우 main 에 일부 코드를 작성하는 것이 Try 및 Terminate 를 구현하는 새 유형을 만드는 것보다 더 낫다고 생각합니다. Terminate 의 요점은 라이브러리가 쉽게 좋은 기본값을 만들 수 있는 것이므로 프로그램이 종료되는 방식이 최종 사용자(예: 전문 CLI)에게 중요한 상황에서는 결코 그렇지 않습니다. .

물론 다른 사람들은 다른 의견을 가질 수 있으며 main 에 직접 작성하는 대신 코드를 삽입하는 데 관련된 특성을 사용하는 여러 가지 방법이 있습니다. 좋은 점은 우리가 여러 가지 선택을 할 수 있고 항상 오류를 처리하기 위해 하나의 축복받은 방법을 생각해낼 필요가 없다는 것입니다.

몇 가지 문제가 있지만 몇 가지 생각을 적어 보겠습니다.

다음을 보고 싶습니다.

fn main() -> i32 {
    1
}

더 일반적으로 다음과 같이 작성할 수 있습니다.

fn main() -> impl Display {
    1
}

이 두 주요 함수는 모두 0 종료 코드와 println! 의 Display 를 반환해야 합니다.

이것은 다음과 같이 간단해야 합니다(제 생각에는).

impl<T> Termination for T where T: Display {
    fn report(self) -> i32 {
        println!("{}", self);
        EXIT_SUCCESS
    }
}

그런 다음 오류에 대해 다음을 수행할 수 있습니다.

impl<T: Termination, E: Debug> Termination for Result<T, E> { ... }

여기서 구현은 "{:?}" 를 사용하는 RFC와 동일합니다.
Debug 형식.

앞에서 언급했듯이 출력을 더 많이 제어해야 하는 사람들은 간단히
쓰다:

fn main() -> Result<i32, MyError> { ... }
impl Termination for Result<i32, MyError> { ... }

이것은 현재 컴파일러로 결정할 수 없지만
충돌하는 구현을 보게 될 것입니다 ... 그래서 우리는 @nikomatsakis 가 제안한 것을 수행합니다
쓰기:

fn main() -> MyResult { ... }
impl Termination for MyResult { ... }
or, if you want something more general.
impl<T, E> Termination for MyResult<T, E> { ... }

나는 이것이 부분적으로 말한 것을 다시 말하고 있다는 것을 알고 있지만 결과뿐만 아니라 반환 값을 표시하기 위한 보다 일반적인 솔루션을 보여주기 위해 내 비전을 모두 제시할 것이라고 생각했습니다. 이 의견의 많은 부분이 기본적으로 제공되는 Termination 구현에 대해 논쟁하는 것 같습니다. 또한 이 주석은 RFC에 설명된 대로 impl Termination for bool 와 같은 구현과 모순됩니다. 개인적으로 0이 아닌 종료 코드는 Results 또는 Termination 를 구현하는 사용자 정의 유형에 의해 독점적으로 처리되어야 한다고 생각합니다.

Display 에 대한 구현이 없기 때문에 main의 Option 유형에서 ? 를 처리하는 방법에 대한 흥미로운 질문입니다.

TL;DR: Debug 는 괜찮습니다.

더 자세한 설명:
나는 가능한 한 최선의 답에 도달하는 데 도움을 주기 위해 내가 가지고 있거나 만들고 있는 암묵적인 가정을 밝히는 것을 목표로 어제와 오늘 이것에 대해 생각하는 데 시간을 보냈습니다.

주요 가정: Rust로 작성할 수 있는 모든 다양한 유형의 애플리케이션 중에서 콘솔 앱이 이 결정의 가장 큰 혜택을 받거나 가장 큰 영향을 받을 것이라고 생각합니다. 내 생각은 라이브러리, AAA 게임 타이틀, IDE 또는 독점 제어 시스템을 작성할 때 기본 기본 종료 특성이 기본적으로 필요한 요구 사항을 충족할 것이라고 기대하지 않을 수 있다는 것입니다. 기본). 따라서 기본적으로 Display 에 대한 나의 편견은 작은 명령줄 응용 프로그램을 사용할 때 볼 것으로 예상되는 것에서 비롯됩니다. 예를 들면 다음과 같습니다.

$ cd foo
bash: cd: foo: No such file or directory

우리 대부분은 어떤 종류의 디버깅 지원도 기대하지 않고 무엇이 잘못되었는지에 대한 간결한 표시기만 기대합니다. 나는 이것을 기본 입장으로 옹호할 뿐입니다.

이와 같은 간단한 출력을 얻기 위해 Terminate impl을 작성하는 것을 생각할 때 주요 기능의 ? 가 오늘날의 안정적인 녹과 별반 다르지 않다는 것을 깨달았습니다(작성된 코드의 양 측면에서 ), 여기서 Result -aware "inner_main()" 은 E 를 처리하기 위해 종종 생성됩니다.

이 가정을 염두에 두고, 사고 연습으로, 오늘날 존재하는 " inner_main() " 스타일 구현이 더 캐주얼한 Display 풍미를 가지고 있다고 강하게 느꼈는지 여부를 결정하려고 했습니다. (보다 기술적인 Debug 풍미 이상). 내 생각은 이것이 기능이 실제로 어떻게 사용될 가능성이 있는지를 나타내는 것이었습니다.

나는 이것이 사실인지 확신 할 수 없었다 . (즉, 현재 기존 구현에서 Display 에 대한 강한 편향이 있다고 생각하지 않습니다.) 실제로 지난 16개월 동안 작성한 내 저장소를 살펴보면 기본적으로 Display 를 구현하는 것이 순 절감액에 해당한다고 말할 수 없는 두 경우 모두를 충분히 찾았습니다.

"기본 수혜자는 cli 애플리케이션"이라는 가정을 유지하면서 도움말 및 사용 정보를 제공하는 콘솔 앱이 많이 있습니다. 예를 들어:

$ git foo
git: 'foo' is not a git command. See 'git --help'.

The most similar command is
    log

그래서 콘솔 앱에서도 Debug 로 '부상 그룹'을 식별하기가 어렵습니다.

그리고 마지막으로 6개월 동안 기능을 유지하는 것보다 Debug impl을 사용하는 것이 더 행복할 것입니다.

그래서 내 사고 과정이 공개적으로 공개됩니다. 요약하자면 Debug 가 Display 보다 좋지도 나쁘지도 않을 것이며 기본 구현으로 괜찮을 것입니다.

많은 분들이 그러하듯이, TBH에서 "예, 그렇군요!!!"와 같이 더 흥분되는 구현이 있었으면 하는 바램입니다. 하지만 그것은 비현실적인 내 기대치일 수도 있습니다... 아마도 우리가 프로젝트에서 상용구를 줄이는 failure 와 함께 작동하는 솔루션을 갖게 된다면 그것은 나에게 더 커질 것입니다. :)

참고 테스트에서 종료 특성을 지원하기 위해 PR을 열었습니다. #48143( @bkchr 의 작업을 기반으로 함).

테스트 결과를 처리하는 메소드로 Termination 트레잇을 확장하는 자유를 얻었습니다. 이것은 구현을 단순화했지만 테스트 실패는 실행 실패보다 더 자세한 출력을 원할 수 있기 때문에 의미가 있습니다.

Termination 는 libstd의 특성에 대한 동사에 대한 일반적인 기본 설정에 따라 Terminate 로 이름을 바꿔야 합니다.

@withoutboats 어느 시점에서 동사 특성은 대부분 특성과 이름이 같은 단일 메서드를 갖는 특성이라는 논의가 있었던 것 같습니다. 어쨌든, 내 자신의 자전거 보관소 제안 Exit 을 다시 띄울 수 있습니까?

무상 자전거 셰딩: 이것은 단일 방법 특성입니다. 같은 이름을 지정하려면 ToExitCode / to_exit_code ?

Result 반환 안정화는 트레잇 안정화와 별개로 수행할 수 있습니다.

나에게 이것은 대부분의 가치가 언어 기능에서 오는 ? 와 매우 유사하며 특성 파악을 지연할 수 있습니다. RFC 토론은 inner_main 에 코드를 넣는 것이 이것을 위한 특성 impl보다 더 쉬워 보였기 때문에 _ever_ 특성을 안정화해야 하는지조차 궁금하게 만들었습니다...

예, 특성을 안정화할 필요는 없습니다. 그러나 inner_main 에 크게 의존할 수 없는 프레임워크와 같은 안정적인 항목에서는 유용합니다.

@SimonSapin To 는 유형 변환을 참조하는 것으로 생각하지만 그렇지 않습니다. 하지만 메서드 이름을 terminate Try 지정할 수 있습니다.

나는 T 가 단위가 아닌 fn main() -> T 를 안정화하자고 제안했습니다. 이로 인해 많은 세부 사항, 특히 특성의 이름/위치/세부 사항이 불안정해졌지만 일부는 수정되었습니다. 세부 정보:

https://github.com/rust-lang/rust/issues/48453

피드백을 주세요!

terminate 가 report 보다 더 설명적인 것 같습니다. 우리는 항상 terminate 하지만 report ing을 생략할 수 있습니다.

그러나 예를 들어 std::process::exit 와 달리 이 메서드는 아무 것도 종료하지 않습니다. main() 의 반환 값만 종료 코드로 변환합니다(선택적으로 Result::Err 를 stderr로 인쇄한 후).

Exit 에 대한 또 다른 투표입니다. 나는 그것이 간단하고 매우 설명적이고 종료 코드/종료 상태에 대한 전통적인 개념과 일치하는 것을 좋아합니다.

나는 확실히 Exit 보다 Terminate 를 더 선호합니다. 왜냐하면 뭔가가 정말 잘못되어서 갑자기 하드 종료하는 것보다 main에서 돌아와서 우아하게 종료하기 때문입니다.

결과를 반환하는 안정화 단위 테스트를 제안하기 위해 https://github.com/rust-lang/rust/issues/48854 를 추가했습니다.

오, 이 얘기를 하기에 적당한 곳을 찾았습니다.

doctest에서 ? 사용

현재 doctest가 작동하는 방식은 다음과 같습니다.

• Rustdoc은 fn main 를 선언하는지 doctest를 스캔합니다.
  
  
  
  • (현재는 // 뒤에 있지 않은 "fn main"에 대한 줄 단위 텍스트 검색을 수행합니다)
  
  
• fn main 가 발견되면 이미 있는 것을 건드리지 않습니다.
• fn main 가 발견되지 않으면 대부분의* doctest를 기본 fn main() { } 로 래핑합니다.
  
  
  
  • *정식 버전: #![inner_attributes] 및 extern crate 선언을 추출하여 생성된 기본 함수 외부에 배치하지만 나머지는 모두 내부에 들어갑니다.
  
  
• doctest에 extern crate 문이 포함되어 있지 않으면(그리고 문서화되는 crate는 std 라고 하지 않음) rustdoc은 생성된 main 함수 바로 앞에 extern crate my_crate; 문도 삽입합니다.
• 그런 다음 Rustdoc은 테스트 도구의 일부로 최종 결과를 독립 실행형 바이너리로 컴파일하고 실행합니다.

(몇 가지 세부 사항을 남겼지만 편리하게 여기에 전체를 작성했습니다.)

따라서 ? 를 doctest에서 원활하게 사용하려면 fn main() { your_code_here(); } 가 추가되는 부분을 변경해야 합니다. 자신의 fn main() -> Result<(), Error> $ 선언은 최대한 빨리 작동합니다. 일반 코드에서 - Rustdoc은 거기에서 수정할 필요조차 없습니다. 그러나 main을 수동으로 선언하지 않고 작동하게 하려면 약간의 조정이 필요합니다. 이 기능을 자세히 따르지 않았기 때문에 만능 솔루션이 있는지 확신할 수 없습니다. fn main() -> impl Termination 가능한가요?

fn main() -> impl 종료가 가능합니까?

얕은 의미에서 그렇습니다: https://play.rust-lang.org/?gist=8e353379f77a546d152c9113414a88f7&version=nightly

불행히도 -> impl Trait 는 내장된 오류 변환으로 인해 ? 에서 근본적으로 번거롭다고 생각합니다. 이 오류 변환에는 어떤 유형을 사용할지 알려주기 위해 추론 컨텍스트가 필요합니다: https://play.rust- lang.org/?gist=23410fa4fa684710bc75e16f0714ec4b&version=nightly

개인적으로 나는 fn main() -> Result<(), Box<Debug>> catch { your_code_here(); } ( https://github.com/rust-lang/rfcs/pull/2107 )와 같은 것을 통해 작동하는 ? -in-doctests를 fn main() -> Result<(), Box<Debug>> catch { your_code_here(); }로 상상하고 있었습니다. github.com/rust-lang/rust/issues/41414#issuecomment-373985777).

impl Trait 버전은 멋지고, Rustc가 ? desugar에서 내부적으로 사용할 수 있는 "제약 없는 경우 동일한 유형을 선호" 지원이 있는 경우 작동할 수 있지만 제 기억은 다음과 같습니다. 그런 기능에 대한 아이디어는 작동 방식을 이해하는 사람들을 공포에 떨게 만드는 경향이 있습니다. :sweat_smile: 하지만 출력이 impl Trait 인 경우에만 적용되는 내부 문제일 수도 있습니다.

오, 그것들은 매우 현실적인 우려입니다. 그것이 형식 추론을 망칠 수 있다는 사실을 잊어버렸습니다. catch 블록이 연결된 문제와 같이 Ok-wrapping을 시작했다면 훨씬 더 쉽고(훨씬 빠르고, 안정화 측면에서) 경로가 더 빨라진 것 같습니다.

내가 궁금한 유일한 것은 그것이 에디션 전환에 의해 어떻게 영향을 받을지입니다. catch 구문이 2018 시대에 변경되지 않습니까? Rustdoc은 실행 중인 라이브러리와 동일한 에디션에서 doctest를 컴파일하기를 원할 것이므로 전달된 epoch 플래그를 기반으로 구문을 구별해야 합니다.

나는 이것이 이제 안정화되었지만 단순한 경우는 분명히 여전히 ICE에 대해 우려하고 있습니다. https://github.com/rust-lang/rust/issues/48890#issuecomment -375952342

fn main() -> Result<(), &'static str> {
    Err("An error message for you")
}

assertion failed: !substs.has_erasable_regions(), librustc_trans_utils/symbol_names.rs:169:9

https://play.rust-lang.org/?gist=fe6ae28c67e7d3195a3731839d4aac84&version=nightly

어느 시점에서 "이것은 너무 버그가 있고 불안정해야 합니다"라고 말합니까? 이것이 현재의 형태로 안정적인 채널에 부딪히면 많은 혼란을 일으킬 것 같습니다.

@frewsxcv 이제 문제가 해결된 것 같은데요?

@nikomatsakis 내가 https://github.com/rust-lang/rust/issues/48389 에서 제기한 문제는 1.26-베타에서 해결되었으므로 내 관점에서 그렇습니다.

네, 걱정했던 ICE가 이제 해결되었습니다!

이 문제에 대해 아무것도 하기에는 너무 늦은 시점에 끼어들어서 죄송합니다. 하지만 만일의 경우를 대비하여 여기에 제 피드백을 남기고 싶었습니다. 나는 이 스레드의 대부분을 읽었으므로 그 맥락을 염두에 두고 이야기합니다. 그러나 이 쓰레드는 길기 때문에 제가 간과한 부분이 있다면 아마 간과했을 것이고 지적해 주시면 감사하겠습니다. :-)

TL;DR - 오류의 Debug 메시지를 표시하는 것은 실수라고 생각하며 더 나은 선택은 오류의 Display 메시지를 사용하는 것입니다.

내 믿음의 핵심은 _일상적으로 Rust에서 CLI 프로그램을 빌드하는_ 사람으로서 Error 의 Debug 메시지가 무엇인지에 대해 별로 신경을 쓴 기억이 없다는 것입니다. 즉, Debug 오류는 의도적으로 최종 사용자가 아닌 개발자를 위한 것입니다. CLI 프로그램을 빌드할 때 해당 인터페이스는 기본적으로 최종 사용자가 읽을 수 있도록 되어 있으므로 Debug 메시지는 여기에서 거의 유용하지 않습니다. 즉, 내가 최종 사용자에게 제공한 CLI 프로그램이 정상적인 작동에서 Rust 값의 디버그 표현을 보여주었다면 버그가 수정된 것으로 간주할 것입니다. 합리적인 사람들이 동의하지 않을 수 있다는 점을 이해하지만 일반적으로 이것이 Rust로 작성된 모든 CLI 프로그램에 해당되어야 한다고 생각합니다. 그렇긴 하지만, 제 생각에 다소 놀라운 의미는 기본 작동 모드가 수정되어야 하는 버그(IMO)로 시작하는 기능을 효과적으로 안정화했다는 것입니다.

기본적으로 오류의 Debug 표시를 표시함으로써 잘못된 관행을 권장한다고 생각합니다. 특히, Rust CLI 프로그램을 작성하는 과정에서 오류의 Display impl조차도 최종 사용자가 소비하기에 충분하지 않으며 실제 작업을 수행해야 한다는 것을 관찰하는 것은 매우 일반적입니다. 그것을 고친다. 이에 대한 구체적인 예는 io::Error 입니다. 해당 파일 경로 없이 io::Error 표시(파일 읽기/쓰기/열기/생성에서 온 것으로 가정)는 기본적으로 버그입니다. 왜냐하면 최종 사용자가 이것으로 아무것도 하기 어렵기 때문입니다. 기본적으로 Debug 오류 표시를 표시하도록 선택하여 CLI 프로그램을 만드는 사람들이 이러한 종류의 버그를 발견하는 것을 더 어렵게 만들었습니다. (게다가 io::Error 의 Debug 은 Display 보다 훨씬 덜 유용하지만 그 자체로는 제 경험상 큰 문제가 되지는 않습니다. )

마지막으로, 내 주장을 마무리하기 위해 예제에서도 ?-in-main 를 사용할 상황을 상상하는 데 어려움이 있습니다. 즉, 실제 프로그램과 최대한 일치하는 예제를 작성하려고 노력했으며 일반적으로 다음과 같이 작성했습니다.

use std::error::Error;
use std::process;

fn try_main() -> Result<(), Box<Error>> {
    // do stuff with `?`
}

fn main() {
    if let Err(err) = try_main() {
        eprintln!("{}", err);
        process::exit(1);
    }
}

겉보기에는 이것을 ?-in-main 로 바꾸는 것이 _사랑스러운_ 일이지만 Display 오류가 표시되지 않기 때문에 그렇게 할 수 없습니다. 즉, 실제 CLI 프로그램을 작성할 때 실제로 위의 방식을 사용하게 되므로 내 예제가 현실을 반영하고 싶다면 지름길을 취하지 않고 실제 프로그램에서 수행하는 작업을 보여야 한다고 생각합니다(합리적인 범위 내에서 ). 저는 실제로 이런 종류의 것이 정말 중요하다고 생각합니다. 역사적으로 이것의 한 가지 부작용은 unwrap 어디에나 뿌리지 않고 관용적인 Rust 코드를 작성하는 방법을 사람들에게 보여주었다는 것입니다. 그러나 예제에서 ?-in-main 를 사용하는 것으로 되돌아가면 목표를 어긴 것입니다. 이제 기본적으로 매우 잘 방출하는 프로그램을 작성하도록 더 잘 모르는 사람들을 설정하고 있습니다. 도움이 되지 않는 오류 메시지.

"오류 메시지를 내보내고 적절한 오류 코드로 종료" 패턴은 실제로 세련된 프로그램에서 사용됩니다. 예를 들어 ?-in-main 가 Display 를 사용했다면 오늘 ripgrep에서 main 및 run 함수를 병합할 수 있습니다.

https://github.com/BurntSushi/ripgrep/blob/64317bda9f497d66bbeffa71ae6328601167a5bd/src/main.rs#L56 -L86

물론 안정화되면 Termination 트레잇에 대한 고유한 impl을 제공하여 미래에 ?-in-main 를 사용할 수 있지만 main 만 쓸 수 있다면 왜 그렇게 하는 것이 귀찮을까요? impl 를 예제에 포함해야 하며, 그 시점에서 저는 오늘 가지고 있는 예제를 고수할 수도 있습니다( main 및 try_main ).

보기에는 이 문제를 수정하는 것이 큰 변화가 될 것 같습니다 . 즉, 이 코드는 오늘날 Rust stable에서 컴파일됩니다.

#[derive(Debug)]
struct OnlyDebug;

fn main() -> Result<(), OnlyDebug> {
    Err(OnlyDebug)
}

Display 로 전환하면 이 코드가 깨질 것 같습니다. 그러나 나는 확실히 모른다! 이것이 정말로 배를 탔던 문제라면, 나는 이해하고 요점을 설명하는 데 너무 많은 소용이 없지만, 적어도 이것에 대해 충분히 강하게 느끼고 있습니다. 그것을 고칠 수 있는 일이 있다면. (여기서 내가 과민 반응을 보일 수도 있지만 지금까지 두 사람이 내 CSV 예제에서 "왜 ?-in-main 를 사용하지 않습니까?"라고 물었고 내 대답은 기본적으로, "그런 일이 어떻게 가능할지 모르겠습니다." 아마도 그것은 ?-in-main 로 해결될 문제가 아니었지만 일부 사람들은 확실히 그런 인상을 받았습니다. 현재 구현으로 , 문서 테스트와 단위 테스트에서 유용하다고 볼 수 있지만 다른 상황에서 사용할 생각은 어렵습니다.)

Debug Display 를 표시하는 것이 CLI 애플리케이션에 더 좋다는 데 동의합니다. Debug #$ 대신 Display 이어야 한다는 데 동의하지 않습니다. 왜냐하면 그것이 실제로 ? -ed가 될 수 있는 오류를 크게 제한하고 ?-in-main 의 목적을 무효화하기 때문입니다. Display 를 사용할 수 있을 때 사용하고 그렇지 않을 때 Debug 로 대체하는 비중단 방법을 제공합니다.

#[unstable(feature = "termination_trait_lib", issue = "43301")]
impl<E: fmt::Display> Termination for Result<!, E> {
    fn report(self) -> i32 {
        let Err(err) = self;
        eprintln!("Error: {}", err);
        ExitCode::FAILURE.report()
    }
}

마지막으로, 내 주장을 마무리하기 위해 예제에서도 ?-in-main을 사용할 상황을 상상하는 데 어려움이 있습니다.

실제 CLI 프로그램의 경우 일반적으로 @BurntSushi 에 동의해야 하지만 나만 사용할 계획인 임의의 스크립트 및 내부 도구의 경우 이것이 정말 편리합니다. 또한 프로토타입과 장난감에 정말 편리합니다. 프로덕션 코드에서 실제로 사용하는 것을 항상 권장하지 않을 수 있습니다. 그렇죠?

?-in-main의 목표 중 일부는 코드 예제에서 단일 관용어 코드, 즉 unwraps를 피하는 것입니다. 그러나 ?-in-main 자체가 단일 관용어가 되면 전체 기능이 손상됩니다. 프로덕션 코드에서 또는 기타 방식으로 사용을 권장하지 않는 결과를 피하고 싶습니다.

나는 이 기능을 메인에서 사용하려고 노력했는데 꽤 실망스러웠다. 종료 특성의 기존 impls는 여러 종류의 오류를 편리하게 "누적"하는 것을 허용하지 않습니다. 예를 들어, 오류를 구현하지 않기 때문에 failure::Fail을 사용할 수 없습니다. 상자를 사용할 수 없습니다, 같은 이유. 디버그로 변경하는 것을 우선시해야 한다고 생각합니다. =)

Display 를 사용하면 $ MainError 와 같은 빠르고 더러운 유형을 도입하여 여러 종류의 오류를 누적할 수 있습니다.

pub struct MainError {
    s: String,
}

impl std::fmt::Display for MainError {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        self.s.fmt(f)
    }
}

impl<T> From<T> for MainError where T: std::error::Error {
    fn from(t: T) -> Self {
        MainError {
            s: t.to_string(),
        }
    }
}

이것은 Box<Error> 와 유사한 아래와 같은 것을 허용합니다:

fn main() -> Result<(), MainError> {
    let _ = std::fs::File::open("foo")?;
    Ok(())
}

디스플레이 대 디버그에 대한 이전 논의는 https://github.com/rust-lang/rust/issues/43301#issuecomment -362020946에서 시작하는 숨겨진 부분에 있습니다.

@BurntSushi 동의합니다. 이 문제를 해결할 수 없는 경우 해결 방법이 있을 수 있습니다.

use std::fmt;
struct DisplayAsDebug<T: fmt::Display>(pub T);

impl<T: fmt::Display> Debug for DisplayAsDebug {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        fmt::Display::fmt(&self.0, f)
    }
}

impl<T: fmt::Display> From<T> for DisplayAsDebug {
    fn from(val: T) -> Self {
        DisplayAsDebug(val)
    }
}

이것이 std::fmt 에 있으면 다음과 같이 사용할 수 있습니다.

use std::{fmt, io};

fn main() -> Result<(), fmt::DisplayAsDebug<io::Error>> {
    let mut file = File::open("/some/file")?;
    // do something with file
}

나는 가까운 장래에 이것에 더 이상 기여할 시간이 없지만 main의 ? 는 심각한 CLI 프로그램에서 사용할 수 있어야 하며 원래 초안에 기능이 있다는 데 동의합니다. 이를 용이하게 하기 위한 RFC. 그들은 점증주의의 이름으로 떨어졌지만 아마도 다시 방문해야 할 것입니다.

많은 코드가 안정적인 상태에서 사용하기 전에 빨리 완료되면 이전 버전과 호환되지 않는 방식으로 이 문제를 수정하는 것이 좋습니다.

Rust로 많은 CLI 프로그램을 작성하고 직장에서 Rust 스타일을 담당하는 사람으로서 저는 여기에서 @burntushi 에 거의 동의합니다. RFC에 지정된 이 기능의 버전을 기꺼이 사용했을 것입니다.

그러나 Debug 구현을 사용자에게 버그로 표시하는 것을 고려하고 CLI 프로그램의 모든 곳에서 unwrap 를 호출하는 것보다 훨씬 낫지 않습니다. 따라서 예제 코드에서도 이 버전의 기능을 사용하는 것은 상상할 수 없습니다. main 에서 상용구를 제거하면 직장에서 새로운 Rust 개발자를 위한 학습이 단순화되고 quick_main! 또는 이에 상응하는 것을 더 이상 설명할 필요가 없었기 때문에 이것은 너무 나쁩니다.

이것을 사용하는 것을 상상할 수 있는 거의 유일한 상황은 doctest에서 unwrap 를 제거하는 것입니다. 하지만 아직 지원하는지 모르겠습니다.

Display 를 사용하면 $ MainError 와 같은 빠르고 더러운 유형을 도입하여 여러 종류의 오류를 누적할 수 있습니다.

개인적으로 이러한 종류의 해결 방법은 ? -in- main 을 완전히 피하는 것이 더 쉬울 만큼 충분히 복잡합니다.

@아론파워 :

내가 말할 수있는 한 (stdlib를 컴파일 할 시간이없고 전문화가 이것을 다루는지 모르기 때문에 완전히 틀릴 수 있음) 다음 impl을 Termination에 추가하지 못할 이유가 없습니다. 이렇게 하면 디스플레이를 사용할 수 있는 경우 중단하지 않고 사용하고 그렇지 않은 경우 디버그로 대체할 수 있습니다.

이렇게 하면 fn main() -> Result<(), failure::Error> 를 작성할 수 있고 Display 를 사용하여 사람이 읽을 수 있는 멋진 오류가 발생하면 내 주요 관심사를 확실히 만족시킬 것입니다. 그러나 RUST_BACKTRACE=1 failure::Error 에 역추적을 선택적으로 표시하는 문제가 여전히 남아 있다고 생각합니다. failure 처리됩니다.

이것은 얼마 전에 안정화되었으며 Result 의 동작을 실제로 변경할 수 있다고 생각하지 않습니다. 나는 개인적으로 내가 하는 경향이 있는 사용 사례에 대한 현재 동작(빠르고 더러운 스크립트 등)에 매우 만족하지만 더 복잡한 스크립트에서는 원하지 않는다는 데 동의합니다. 그러나 토론 당시 우리는 그 행동을 제어할 수 있는 여러 가지 방법에 대해서도 논의했습니다.

예를 들어, 오류 유형에 대해 고유한 "래퍼"를 정의하고 이에 대해 From 를 구현할 수 있습니다.

struct PrettyPrintedError { ... }
impl<E: Display> From<E> for PrettyPrintedError { }

impl Debug { /* .. invoke Display .. */ }

이제 다음과 같이 작성할 수 있습니다. 즉, main ? 를 사용할 수 있습니다.

fn main() -> Result<(), PrettyPrintedError> { ... }

아마도 그러한 유형은 quick cli 또는 무언가의 일부여야 합니까?

@nikomatsakis 네, 그 해결 방법을 완전히 이해하지만 ?-in-main 사용의 간결함의 목적을 무효화한다고 생각합니다. 불행히도 "이 해결 방법을 사용하여 ?-in-main 를 사용할 수 있습니다"라고 생각하면 불행히도 ?-in-main 자체가 손상됩니다. 예를 들어, 나는 당신의 해결 방법을 간결한 예제로 작성하지 않을 것이며 내가 작성하는 모든 예제에 대해 quicli 에 대한 종속성을 부과하지도 않을 것입니다. 나는 기본적으로 내가 작성하는 모든 CLI 프로그램에서 오류의 Display 출력을 원하기 때문에 빠른 프로그램에도 사용하지 않을 것입니다. 내 생각에는 오류의 디버그 출력이 사용자 앞에 두는 CLI 프로그램의 버그라는 것입니다.

?-in-main 의 대안은 추가 ~4줄 함수입니다. 따라서 ?-in-main 를 수정하여 Display $를 사용하는 해결 방법이 그 이상이라면 개인적으로 사용할 이유가 별로 없습니다(문서 테스트 또는 단위 테스트 제외). 위에 언급했듯이).

에디션에서 변경될 수 있는 항목인가요?

@BurntSushi std 에 있는 해결 방법에 대해 어떻게 생각하시나요? main() 에 대해 좀 더 긴 반환 유형 선언만 작성하면 됩니까?

@Kixunil 첫 느낌은 아마도 맛있을 것 같다. 그래도 너무 많이 생각하지 않았습니다.

@BurntSushi

?-in-main 에 대한 대안은 추가 ~4줄 함수입니다.

궁극적으로 동작은 안정적이며 현 시점에서 현실적으로 변경할 수 없다고 생각합니다. (건전성 위반이 아니라는 뜻입니다.)

즉, 나는 여전히 현재 설정이 Display 보다 훨씬 좋고 선호된다고 생각하지만 "기본값"이 무엇인지에 관한 문제라고 생각합니다. 기타 다양한 newtypes를 통해. 따라서 우리는 기본적으로 Debug 또는 세련된 최종 제품을 원하는 "빠른-앤-더티" 스크립트를 선호합니다. 나는 세련된 최종 제품이 추가 수입을 충분히 쉽게 감당할 수 있는 곳이며 또한 다양한 가능한 형식 중에서 선택하고 싶은 곳이라고 생각하는 경향이 있습니다(예: 오류만 원하는지 아니면 argv를 포함하고 싶은지 [0] 등).

좀 더 구체적으로 말하면 다음과 같을 것이라고 생각합니다.

use failure::format::JustError;

fn main() -> Result<(), JustError> { .. }

또는 다른 형식을 얻으려면 다음을 수행합니다.

use failure::format::ProgramNameAndError;

fn main() -> Result<(), ProgramNameAndError> { .. }

이 두 가지 모두 이전에 작성해야 했던 4줄 함수에 비해 상당히 좋은 느낌을 줍니다.

use std::sys;

fn main() {
  match inner_main() {
    Ok(()) => { }
    Err(error) => {
      println!("{}", error);
      sys::exit(1);
    }
}

fn inner_main() -> Result<(), Error> {
  ...
}

생산 품질을 위해 기본적으로 출력에 대한 사용자 정의 오류 유형에 금액을 추가하는 것이 어쨌든 사람들을 밀어붙이는 좋은 방향인 것 같기 때문에 이 주제에 대해 이야기하고 있습니다. 이것은 예를 들어 panic! 가 기본적으로 디버그 품질 메시지를 제공하는 방식과 유사합니다.

@nikomatsakis 그것은 아마도 더 나은 장기적 관점일 것입니다. 그리고 나는 당신의 최종 결과가 식욕을 돋우고 있다고 생각합니다. 이러한 오류 유형이 언젠가 std 로 끝나서 가능한 한 적은 오버헤드로 예제에서 사용할 수 있다면 좋을 것입니다. :-)

프로세스 노트: 저는 초기 피드백을 "이미 안정화된 것을 바꾸자"가 아니라 "할 수 있는 일이 있습니까?"로 구성하려고 했습니다. 확실히 할 수 없습니다. :-)

오래 걸리지 않았습니다: https://crates.io/crates/exitfailure 😆

Debug 트레잇 대 Display 트레잇을 사용하여 얼마나 많은 사람들이 놀랐는지 궁금합니다. 초기 토론 초안과 최종 RFC 는 모두 Display 를 사용하고 있습니다. 이것은 사람들이 한 가지를 얻고 있다고 생각했지만 안정화된 후에야 다른 것을 얻고 있다는 것을 알게 되는 보편적인 임팩트 특성 사건과 유사합니다. 또한 많은 사람들이 놀라서 이 기능을 사용하지 않을 것이라는 점을 고려할 때 다음 버전에서 변경하면 큰 백슬래시가 없을 것이라고 생각합니다.

@WiSaGaN RFC의 세부 사항은 수시로 변경될 수 있으며 변경될 것입니다. 이것은 예상되고 건강합니다. RFC는 설계 문서이며 현재와 미래에 대한 완벽한 표현이 아닙니다. 정보발굴이 어려운데 더 신경쓰지 않은 내 잘못이다. 이 기능의 안정성에 대한 재검토를 피하고 대신 실행 가능한 조치를 취할 수 있는 더 높은 수준의 목표에 집중할 수 있기를 바랍니다.

@nikomatsakis 빠른 처리를 선호하는 경우의 주요 문제는 .unwrap() 처리할 수 있는 방법이 이미 있다는 것입니다. 따라서 그런 관점에서 보면 ? 는 빠른 속도로 더러운 것을 작성하는 또 다른 방법이지만 세련된 것을 작성하는 이와 비슷하게 쉬운 방법은 없습니다.

물론 배가 출항했기 때문에 우리는 대부분 망했습니다. 가능하다면 다음 판에서는 이것이 변경되는 것을 보고 싶습니다.

@Kixunil , unwrap 는 이 스레드의 제목이 main $에서 구문 설탕 ? 을 사용할 수 있기를 원한다고 나와 있으므로 실제로 문제를 해결하는 좋은 방법이 아닙니다. . 나는 당신이 어디에서 왔는지 이해할 수 있지만(사실 그것은 옵션 처리를 위해 ? 를 사용하는 것에 대한 나의 초기 망설임의 일부였습니다) 그러나 언어에 ? 를 포함시키면 이 문제는 꽤 좋은 유용성 승리 IMHO. 더 나은 출력이 필요한 경우 옵션이 있습니다. 먼저 테스트하지 않고 사용자에게 무언가를 릴리스하지 않으며 main 의 출력에 대해 사용자 정의 유형이 필요하다는 발견은 매우 빨리 실현될 것입니다.

"이유"에 관해서는 ? in main , 지금이 얼마나 이상한지 고려하십시오. 다른 모든 곳에서 실제로 사용할 수 있습니다(반환 유형을 제어할 수 있기 때문에). main 함수는 결국 특별하게 느껴지지 않아야 합니다.

.unwrap() 는 구성하지 않는 빠르고 더러운 솔루션이므로 프로그램을 스케치하는 동안 main() 에서 코드를 인수분해할 수 없습니다.

이에 비해 ? 는 작성하는 빠르고 간단한 솔루션이며, 빠르고 간단 하지 않게 만드는 것은 올바른 반환 유형을 main() 에 넣는 문제가 아니라 코드 자체를 수정하는 것.

@Screwtapello 아, 이제 이해가 됩니다. 감사 해요!

추가 래퍼에 의존하지 않고 모든 응용 프로그램에 대해 ? in main 를 가져오는 것이 목표라고 생각했음을 표현하고 싶습니다. 단지 테스트를 위한 것이라면 그렇지 않습니다. 많은 이점이 있으며 슬프게도 .unwrap() 를 계속 고수할 것입니다.

@oblitum 테스트용이 아닙니다. (기본적으로) Display 형식을 사용하지 않습니다. 이것은 당신이 찾고 있는 출력일 수도 있고 아닐 수도 있지만 .unwrap 의 출력보다 거의 확실히 더 나을 것입니다. 즉, ? 를 사용하는 것이 코드를 "더 멋지게" 만들 수 있습니다. 어떤 경우에도 @nikomatsakis 가 위에서 자세히 설명한 대로 main 의 ? 오류 출력을 사용자 정의할 수 있습니다.

디스플레이 케이스의 stdlib 에 newtype을 도입할 수 있습니까? 다음과 같은 것:

#[derive(Clone, Copy, PartialEq, PartialOrd, Eq, Ord, Debug, Hash)]
#[must_use]
struct DisplayResult<E: fmt::Display>(Result<(), E>)

impl<E> Termination for DisplayResult<E> {
    // ... same as Result, but use "{}" instead of "{:?}"
}

impl<E> From<Result<(), E>> for DisplayResult<E> {}
impl<E> Deref<Result<(), E>> for DisplayResult<E> {}
impl<E> Try for DisplayResult<E> {}
// ...

이를 통해 사용자는 다음을 작성할 수 있습니다.

fn main() -> DisplayResult<MyError> {
    // Ordinary code; conversions happen automatically via From, Try, etc.
}

주요 동기는 다음과 같습니다.

• 오류가 반환될 때 디스플레이가 사용됩니다.
• 사용자는 오류 또는 결과 유형을 추가로 래핑할 필요가 없습니다. 그들은 주 기능에서 ? 를 사용할 수 있습니다.

후속 조치: ? 및 From 의 의미 체계로 인해 내가 원하는 만큼 암시적으로 작동하지 않을 수 있습니다. ? 가 From 를 통해 오류 유형 간에 변환된다는 것을 알고 있지만 Try 의 다른 구현자에 대해 동일한 작업을 수행하는지 모르겠습니다. 즉, Result<?, io::Error> 에서 Result<?, FromIoError> 로 변환되지만 반드시 Result<?, Err> 에서 DisplayResult<Result<?, Err>> 로 변환되는 것은 아닙니다. 기본적으로 다음과 같은 작업을 찾고 있습니다.

fn main() -> DisplayResult<io::Error> {
    let f = io::File::open("path_to_file")?;
    let result = String::new();
    f.read_to_string(result)?
}

이것이 작동하지 않는다고 가정하면 대신 Cargo.toml에서 간단한 조건부 컴파일 플래그를 만들 수 있습니까?

@Lucretiel : 프로그래머가 주로 콘솔에 종료 메시지를 인쇄하기를 원한다고 가정하는 것 같습니다. 이것은 비기술적 데스크톱 응용 프로그램, 로깅 배관이 있는 데몬 등에는 적용되지 않습니다. 저는 표준 라이브러리에 있어야 할 강력한 증거(예: 숫자) 없이 '일반적으로 유용한' 항목을 표준 라이브러리에 추가하지 않는 것을 선호합니다.

main Result<(), E> where E: Error 를 반환하는 프로그래머가 콘솔에 오류 메시지를 인쇄하는 데 관심이 있다고 가정합니다. 그렇습니다. Debug 를 통해 인쇄되는 현재 동작조차도 "콘솔에 종료 메시지 인쇄"입니다.

이 스레드에서는 무언가가 stderr에 인쇄되어야 한다는 데 폭넓은 동의가 있는 것 같습니다. 내려야 할 핵심 결정은 " "{}" 또는 "{:?}" 또는 다른 것으로 인쇄해야 하는지, 그리고 있다면 어떻게 구성해야 하는지"입니다.

@Lucretiel , 저에게 Result 를 반환하는 가치는 종료 상태를 멋지게 제어하고 있습니다. 가장 좋지 않은 것을 인쇄할지 여부는 패닉 핸들러에 맡겨야 합니까? stderr에 무엇을 인쇄할지 여부와 무엇을 인쇄할지(역추적, 오류 메시지 등) 문제가 있습니다. https://github.com/rust-lang/rust/issues/43301#issuecomment -389099936, 특히. 마지막 부분.

나는 이것을 최근에 사용했고 Display 라고 부르기를 바랐다. 우리가 여기에서 전화를 잘못 걸었다고 확신합니다.

내가 알아차린 프로세스 실패는 libs 팀이 아니라 lang 팀(주로 Niko와 I)이 결정했지만 문제의 코드는 완전히 std에 있다는 것입니다. 아마도 libs가 더 나은 결정을 내렸을 것입니다.

@withoutboats 너무 늦었나요? 이 기능은 여전히 ​​문서 에서 야간 전용/실험으로 태그가 지정되어 있지만 안정화 프로세스 이면의 세분성을 이해하지 못할 수 있습니다.

나도 이 변경 사항을 보고 싶습니다. 팀에서 구현을 Display 에서 Debug 로 변경하도록 요청했을 때 더 강력한 옹호자가 되지 못한 것을 후회합니다.

@Lucretiel Termination 특성은 야간이지만 기능 자체( main Termination 구현 반환)는 이미 안정적입니다.

특성의 이름을 안정화하기 위한 티켓이나 타임라인이 있습니까?

@xfix 구현을 변경할 수 있다는 뜻이겠죠? 동작은 변경되지 않지만( Termination main ) 특성 자체는 다음과 같이 변경됩니다.

impl<E: Debug> Termination for Result<(), E> ...

에게:

impl<E: Display> Termination for Result<(), E> ...

구현을 변경하는 것이 가능하지 않습니까?

이전 버전과의 호환성을 깨뜨리지 않고는 아닙니다. 이 코드는 오늘날의 안정적인 Rust에서 컴파일됩니다.

#[derive(Debug)]
struct X;

fn main() -> Result<(), X> {
    Ok(())
}

Display 를 요구하도록 제안된 변경으로 컴파일이 중지됩니다.

이미 언급했듯이 전문화와 같은 것이 도움이 될 수 있지만 전문화에 대한 현재 이해는 Display 및 Debug 를 모두 구현하는 유형에만 유용하다는 것입니다(즉, 더 특별한 구현).

trait ResultTerm {
    fn which(&self);
}
impl<T: Debug> ResultTerm for T {
    default fn which(&self) {
        println!("{:?}", self)
    }
}
impl<T: Debug + Display> ResultTerm for T {
    fn which(&self) {
        println!("{}", self)
    }
}

enum MyResult<T, E> {
    Ok(T),
    Err(E),
}

impl<T, E> Termination for MyResult<T, E>
where
    E: ResultTerm,
{
    fn report(self) -> i32 {
        match self {
            MyResult::Err(e) => {
                e.which();
                1
            }
            _ => 0,
        }
    }
}

운동장

이것은 모든 일반적인 경우를 다루기에 충분할 수 있지만 전문화를 공개적으로 노출합니다.

아, 안정적인 녹이 무엇을 의미하는지 알겠습니다. 웬일인지 나는 이것이 안정 상태에서 사용 가능하다는 것을 알지 못했습니다.

이것은 컴파일 타임에 Cargo 플래그로 전환할 수 있는 것입니까? panic = "abort" 와 같이 다른 것들을 전환할 수 있는 것과 같은 방식입니다.

아마도? 다른 Rust 에디션에서 ? 의 main 에 대해 다른 동작을 하는 것이 가능하다는 것을 알 수 있었습니다. 2018년이 아니라 2021년이 아닐까?

동일한 프로그램의 다른 상자는 다른 에디션에 있을 수 있지만 동일한 std 를 사용하므로 std 에서 사용할 수 있는 특성과 해당 impls는 에디션 간에 동일해야 합니다. 우리가 이론상으로 할 수 있는 것은(나는 이것을 옹호하는 것이 아닙니다) Termination 및 Termination2 main() 두 가지 특성을 가지며 하나 또는 main() 를 정의하는 크레이트 버전에 따라 다릅니다.

나는 우리가 어떤 것도 폄하할 필요가 없다고 생각합니다. 현재 상황이 프로덕션 사용자를 불만족시키는 것과 같은 방식으로 디스플레이 유형으로만 제한하면 퀵 스크립트 사용자(디버그를 파생시키는 것은 사소하고 디스플레이를 구현하는 것은 쉽지 않음)를 만족시킬 수 있다는 @Aaronepower 의 감정을 반영하겠습니다. 우리가 할 수 있다 하더라도 그것이 궁극적으로 우리에게 이익이 될 것이라고는 생각하지 않습니다. @shepmaster 가 제시한 전문화 접근 방식은 다음 동작을 생성한다는 점에서 약속이 있다고 생각합니다.

1. 디버그가 있지만 디스플레이가 없는 유형은 기본적으로 디버그 출력을 인쇄합니다.
2. 디버그와 디스플레이가 모두 있는 유형은 기본적으로 디스플레이 출력이 인쇄됩니다.
3. 디스플레이가 있지만 디버그가 없는 형식은 컴파일러 오류를 발생시킵니다.

Display가 있는 유형이 있지만 어떤 이유로든 Debug를 인쇄하기를 원하는 경우 누군가가 2번 항목에 이의를 제기할 수 있습니다. 이 경우는 미리 설계된 다양한 출력 형식 오류 유형에 대한 Niko의 제안으로 해결될 것이라고 생각합니다.

포인트 3에 관해서는 약간 버벅거립니다(아마도 1.0에서 trait Display: Debug 를 다시 했어야 했을까요?). 하지만 누군가가 Display impl을 작성하는 데 어려움을 겪었다면 그들에게 뺨을 때리도록 요청하는 것은 그다지 중요하지 않습니다. 단일 파생(내 생각에 그들은 아마도 어쨌든 가지고 있다고 생각합니다... 디스플레이 유형에 디버그를 사용하는 것을 원칙적으로 반대하는 사람이 있습니까?).

디스플레이 유형으로만 제한하는 것은 빠른 스크립트 사용자를 불만족스럽게 만들 수 있습니다(디버그를 유도하는 것은 간단하고 디스플레이를 구현하는 것은 그렇지 않음)

빠른 스크립트에서 Display 가 Debug 보다 선호되는 경우는 &'static str 또는 String 를 오류 유형으로 사용하는 것입니다. #[derive(Debug)] 를 적용할 사용자 지정 오류 유형이 있는 경우 이미 오류 처리에 사소한 에너지를 소비하고 있는 것입니다.

@SimonSapin 빠른 스크립팅 환경에서 바람직하지 않거나 노력하지 않고 문자열을 Display 형식으로 인쇄하려는 위치에 있을 정도로 바람직하지 않다고 말하고 싶습니다. 올바른 형식의 오류가 있으려면 나에게 Debug 가 선호됩니다. 왜냐하면 그것이 String일 때 오류 형식이 잘 형성되지 않아서 Err("…") 주위에 있으면 다른 오류에서 쉽게 시각적으로 오류를 선택할 수 있기 때문입니다. 출력되었을 수 있습니다.

FWIW 형식은 Result<_, E> 값이 아니라 내부에 E 값만 있습니다. 따라서 출력에 Err( 가 표시되지 않습니다. 그러나 현재 코드는 Error: 접두사를 추가합니다. Display 가 사용되면 아마도 그대로 있을 것입니다. 따옴표를 인쇄하지 않는 것 외에도 Display 는 사용자에게 (오류) 메시지를 표시할 때 바람직한 IMO인 문자열의 내용을 백슬래시로 이스케이프하지 않습니다.

https://github.com/rust-lang/rust/blob/cb6eeddd4dcefa4b71bb4b6bb087d05ad8e82145/src/libstd/process.rs#L1527 -L1533

주어진 상황에서 우리가 할 수 있는 최선은 Display impl을 인쇄하기 위해 Display + Debug 를 구현하는 유형을 전문화하는 것입니다. Debug 를 구현하지 않는 유형이 오류로 사용될 수 없다는 것은 불행한 일이지만 (교차 impls를 지원할 때까지) 우리가 할 수 있는 최선입니다.

주요 질문은 해당 impl이 std의 특수 impls에 대한 현재 정책에 해당하는지 여부입니다. 우리는 일반적으로 동작이 나중에 변경되지 않는다는 안정적인 보장을 제공하지 않는 std에서만 전문화를 사용한다는 규칙이 있습니다(전문화 자체가 불안정한 기능이기 때문에). 우리가 결국 특성화를 기능으로 제거하면 언젠가 이러한 유형이 Debug 출력으로 되돌아갈 가능성이 있다는 것을 인식하고 이 impl을 제공하는 것이 편안합니까?

사실 이 전문화는 불건전함을 불러일으킬 수 있기 때문에 지금 당장은 허용할 수 없다고 생각합니다. 이 impl 은 실제로 우리에게 많은 문제를 일으키는 종류의 전문화입니다!

use std::cell::Cell;
use std::fmt::*;

struct Foo<'a, 'b> {
     a: &'a Cell<&'a i32>,
     b: &'b i32,
}

impl<'a, 'b> Debug for Foo<'a, 'b> {
    fn fmt(&self, _: &mut Formatter) -> Result {
        Ok(())
    }
}

impl<'a> Display for Foo<'a, 'a> {
    fn fmt(&self, _: &mut Formatter) -> Result {
        self.a.set(self.b);
        Ok(())
    }
}

현재 전문화가 작동하는 방식 때문에 'b 가 'a 보다 오래 지속되지 않는 Foo<'a, 'b> report 를 호출할 수 있으며 현재 컴파일러는 수명 요구 사항이 충족되지 않더라도 Display 인스턴스를 호출하는 impl을 선택하여 사용자가 참조의 수명을 잘못 연장할 수 있도록 합니다.

나는 너희들에 대해 알지 못하지만 내가 빠른 "스크립트"를 작성할 때 나는 모든 것을 unwrap() 그냥 버린다. 컨텍스트 정보를 제공하는 역추적이 있기 때문에 100배 더 좋습니다. 그것 없이는 내 코드에 let ... = File::open() 가 두 번 이상 있는 경우 어느 것이 실패했는지 이미 식별할 수 없습니다.

나는 너희들에 대해 알지 못하지만 내가 빠른 "스크립트"를 작성할 때 나는 모든 것을 unwrap() 그냥 버린다. 컨텍스트 정보를 제공하는 역추적이 있기 때문에 100배 더 좋습니다. 그것 없이는 내 코드에 let ... = File::open() 가 두 번 이상 있는 경우 어느 것이 실패했는지 이미 식별할 수 없습니다.

이것이 실제로 내가 Display 에 대해 그렇게 강하게 느끼는 이유입니다. 왜냐하면 일반적으로 이 경우에 내가 하는 일은 파일 이름 및 기타 관련 컨텍스트 정보를 첨부하는 map_err 하기 때문입니다. 일반적으로 디버그 출력은 내 경험상 실제로 무엇이 잘못되었는지 추적하는 데 덜 도움이 됩니다.

@Kixunil : 또는 더 정교한 오류 처리 전략 및/또는 더 광범위한 로깅 및/또는 디버깅을 선호합니다.

"RFC 구현"이 체크될 수 있다고 생각합니다. 맞죠? 적어도 이것 에 따르면 ! :웃다:

이것이 완전히 단서가 아니라면 실례합니다. 그러나 가능하면 전문화를 사용하여 오류 체인을 보고할 수 없습니다.

use std::error::Error;

impl<E: fmt::Debug> Termination for Result<!, E> {
    default fn report(self) -> i32 {
        let Err(err) = self;
        eprintln!("Error: {:?}", err);
        ExitCode::FAILURE.report()
    }
}

impl<E: fmt::Debug + Error> Termination for Result<!, E> {
    fn report(self) -> i32 {
        let Err(err) = self;
        eprintln!("Error: {:?}", err);

        for cause in Error::chain(&err).skip(1) {
            eprintln!("Caused by: {:?}", cause);
        }
        ExitCode::FAILURE.report()
    }
}

https://github.com/rust-lang/rfcs/blob/f4b8b61a414298ba0f76d9b786d58ccdc34a44bb/text/1937-ques-in-main.md#L260 -L270

impl<T: Termination, E: Display> Termination for Result<T, E> {
    fn report(self) -> i32 {
        match self {
            Ok(val) => val.report(),
            Err(ref err) => {
                print_diagnostics_for_error(err);
                EXIT_FAILURE
            }
        }
    }
}

RFC의 이 부분이 구현되지 않은 이유가 있습니까?

우리는 사용할 특성과 암시의 정확한 세트를 약간 변경했습니다. 하지만 이 시점에서 세부 사항은 기억나지 않습니다. 그리고 안정화해야 할 몇 가지 세부 사항이 남아 있다고 생각합니다. 자세한 내용은 상위 문제에서 링크된 안정화 보고서를 확인하는 것이 좋습니다.

이 기능의 상태는 무엇입니까? 안정화에 대한 제안이 있습니까?

@GrayJack 이 문제는 꽤 오래전에 나왔으므로 종료되어야 합니다.

사실, 그리고 약간 혼란스러워서 Termination 트레잇의 링크에서 여기로 왔고 이에 대해 질문했습니다 termination_trait_lib 에 적절한 문제가 있습니까?

이 문제는 닫아야 합니다

이 문제는 Termination 의 안정화를 추적하기 위해 아직 열려 있습니다.