"return"을 사용하면 레이블이 지정된 ? (tryop 물음표 연산자 물건)에 흥미로운 의미가 있습니다.

break 대신 return을 키워드로 사용하시겠습니까?

@mark-im과 @joshtriplett 는 이미 반환에 반대하는

break(및 continue)는 루프에서만 사용할 수 있습니다.
끊을 수 있는 것이 있으면 계속할 수 있습니다. (블록에서 계속하기 위해 선택할 명백한 구문이 없다고 생각합니다.)

C, C++, Java, C#, JavaScript 및 아마도 더 많은 언어에서 일반적으로 fall-through를 방지하기 위해 switch 문을 break 합니다. Rust는 이 문제를 훨씬 더 멋지게 해결했습니다. | 패턴에 있지만 해당 언어에서 온 사람들은 실제로 break 를 for 루프 전용으로 보지 않을 것입니다. 자바와 자바 스크립트를 통해 기능을 노출, 특히 break 뿐만 아니라 return .

그러나 "기억해야 할 규칙" 주장은 다른 방향으로 잘 작동합니다. 내가 말할 수있는 것은 언급 된 언어와 Rust의 공통점은 반환이 함수에만 적용되고 다른 것은 적용되지 않는다는 것입니다. 따라서 리턴을 보면 함수가 남아 있다는 것을 알 수 있습니다.

블록에 레이블을 지정해도 레이블이 지정되지 않은 기존 나누기에 오류가 발생하지 않습니다.

첫째, 레이블이 지정된 중단 기능이 1000줄당 10번 사용되는 것이 아니기 때문에 이런 일이 매우 드물게 발생한다고 생각합니다. 결국, 그것은 블록의 경계를 가로지르는 레이블이 지정되지 않은 휴식에만 적용되며, 블록 내부에 레이블이 지정되지 않은 휴식에는 적용되지 않습니다. 둘째, Rust 사용자는 컴파일러의 불만/오류 메시지에 익숙하므로 기꺼이 고칠 것입니다! 세 번째(이것이 내가 생각하는 가장 강력한 점입니다), 블록에 레이블을 지정하는 대신 루프로 래핑하는 경우 레이블이 지정되지 않은 중단을 이미 주의해야 하고 break 문을 편리하게 나열하는 오류 메시지가 없는 경우 그들을 직접 사냥하십시오 :).

특히 Java 및 JavaScript는 break를 통해 기능을 노출하고 반환하지 않기 때문에 특히 그렇습니다.

이것은 나에게 킬링 포인트입니다. break from block은 많은 언어에서 사용됩니다. 블록에서 반환...별로.

개인적으로, 나는 공유 @joshtriplett의 사용에보기 break 대신 return 당신이 질문을 믿는다면 토론은 ...은 RFC에 해결되지 않은 것처럼, 그러나 그것은 나에게 듯 lang 팀에서 해결된 경우 메모가 있는 상자에 체크 표시 =)

내가 이 일을 하고 있다는 말만. 멘토 지시가 필요하지 않습니다. 어떤 노력도 반복하지 않기 위해서입니다. 곧 PR을 기대하십시오.

나는 찬성 여전히 해요 return 이상 break ,하지만 난 여기에 동의하지 않을 것에 동의 할 수 있습니다. 질문이 해결되었습니다.

현재( rustc 1.28.0-nightly (a1d4a9503 2018-05-20) ) rustc는 레이블이 지정된 블록에서 unsafe 를 허용하지 않습니다. 예상되는 일입니까?

@topecongiro 예, 현재 일반 블록에서만 허용되는 것이 의도적이라고 생각합니다. 앞으로 바뀔 수도 있겠지만, 워낙 저급하고 이례적인 기능이라는 점을 감안할 때 제약보다는 기능이 되는 쪽으로 방향을 잡았다. (극단적으로 나는 else 'a: { 원하지 않습니다.)

확실히 동의합니다. 안전하지 않은 + 비정상적인 제어 흐름은 낙담할 것처럼 들립니다.

그러나 핀치에서 다음을 사용할 수 있습니다.

'a: {
unsafe {...}
}

오른쪽?

사실, else는 새로운 어휘 범위를 생성하지만 블록이 아닙니다. 전체 if-else는 블록입니다(일종의). 따라서 아니요, else 'a: { 를 얻지 못하고 'a: if ... else { 얻습니다.

else 에는 블록(표현식)이 있습니다. 블록이 없는 "새로운 어휘 범위"는 없습니다.
else 보다 더 나쁜 표면 구문 위치는 'a: while foo 'b: {...} 입니다.
(흥미롭게도 continue 'a 는 break 'b 입니다. 최소한 내부적으로는 이에 의존하고 싶을 수도 있습니다.)

(흥미롭게도 continue 'a 은 break 'b 입니다. 최소한 내부적으로는 이에 의존하고 싶을 수도 있습니다.)

훌륭한 관찰입니다!

레이블은 블록 자체가 아니라 블록을 포함하는 표현식의 일부여야 한다고 생각합니다. 우리는 이미 loop 대한 선례를 가지고 있습니다. (사실, 일반 블록 자체도 블록을 포함하는 표현식입니다. 하지만 if 및 loop 와 같은 것은 블록이 아닌 블록 포함 표현식입니다.)

( while 또는 for 은 레이블 구분 값을 지원하지 않아야 합니다. 정상적으로 완료되는지 또는 break 완료되는지에 따라 값을 반환할 수 있거나 반환할 수 없기 때문입니다. .)

@eddyb

(흥미롭게도 continue '는 break 'b입니다. 최소한 내부적으로는 그것에 의존하고 싶을 수도 있습니다.)

break 'b 루프 조건을 다시 확인하는 경우에만...

@mark-im 'a: while foo {'b: {...}} 와 동일합니다. break 는 루프 조건을 확인하지 않으며 루프 자체는 루프 조건이 본문 블록의 각 반복 전에 확인되기 때문에 루프 자체가 합니다.

와, _매우_ 직관적이지 않습니다. break 'b 이 기본적으로 goto 'b break 'b 가 될 것으로 예상합니다. 즉, 루프 본문을 종료하지 않고 조건을 다시 확인하지 않습니다...

오 :man_facepalming: 알겠습니다...

이것이 내가 레이블이 붙은 break/continue를 좋아하지 않는 이유입니다 :/

음, 우리는 특별히 내가 문제가 표시되지 않도록, 이상한 내부 블록에 라벨을 할 수있는 능력이 없습니다. break 항상 "이 블록에서 나가기"를 의미하며 위의 제한 사항을 감안할 때 "관련 닫는 중괄호 뒤에 있는 지점으로 이동" 이외의 의미는 없습니다.

내 혼란은 이상한 내부 블록에만 국한된 것은 아니지만 토론을 다시 시작하고 싶지는 않습니다. 그것은 이미 일어났고 커뮤니티는 그것을 추가하기로 결정했습니다.

좋아요, 접근성이 프로그래밍 언어의 큰 문제라는 것을 이해합니다... 그러나 레이블이 붙은 break는 저와 같은 코드를 작성하는 경우 매우 유용합니다.

그렇다면 레이블이 지정된 break를 더 쉽게 액세스할 수 있는 방법은 무엇입니까?

그렇다면 레이블이 지정된 break를 더 쉽게 액세스할 수 있는 방법은 무엇입니까?

좋은 질문입니다. 내가 가진 몇 가지 아이디어:

• 우리는 사람들이 야생에서 이것을 어떻게 사용하는지에 대한 몇 가지 샘플을 수집해야 합니다. 우리는 바람직하지 않은 패턴이나 게으른 습관을 찾을 수 있습니다.
• break/continue 레이블을 사용하는 것이 좋지 않은 관행으로 간주될 때 우리는 독단적인 스타일을 가져야 합니다.
• 기계적으로 루프/반복자 결합자로 변할 수 있는 일부 패턴에 대해 린트를 추가할 수 있습니다(하지만 머리로는 그런 패턴이 생각나지 않습니다).

첫 번째 (틀림없이 바이어스) 샘플로서, 실제 코드에 표시된 휴식과 마지막 (먼저) 만남은 별이 아니었다 : https://github.com/rust-lang/rust/pull/48456/files#diff -3ac60df36be32d72842bf5351fc2bb1dL51. 원저자가 조금 더 노력했다면 레이블이 붙은 break 사용을 완전히 피할 수 있었을 것이라고 정중하게 제안합니다... 이것은 가능한 한 권장하지 않는 일종의 관행입니다.

그건... 브레이크라고 표시되지 않았나요?

break 및 continue 설탕 제거 방법에 관해서는 RFC 작성자의 원래 RFC 토론에서도 언급되었습니다. https://github.com/rust-lang/rfcs/pull/2046#issuecomment -312680877 참조

break 라는 이름이 차선책이라고 생각하지만 for 루프에 잘 정립되어 있습니다. 보다 "원칙"접근 구문 사용하는 것 return 'a value 즉시 블록 "후"의 실행을 계속하는 'a 값을 사용하여 value 해당 블록을.

@mark-im "액세스할 수 없기 때문에 기능을 사용하지 않음"은 "해당 기능에 액세스할 수 있도록 만드는 것"이 ​​아닙니다.

어떻게 우리가 레이블이 붙은 break를 조정하여 언어의 완전한 표현력을 얻을 수 있고 동시에 당신의 두뇌가 컴파일러뿐만 아니라 흐름 제어를 처리할 수 없다고 불평하는 것을 멈출 수 있습니까?

(또한 링크한 코드는 RFC 2046/label-break-value와 관련이 없는 것 같습니다... 혹시 잘못된 코드를 링크했습니까?)

그건... 브레이크라고 표시되지 않았나요?

(또한 링크한 코드는 RFC 2046/label-break-value와 관련이 없는 것 같습니다... 혹시 잘못된 코드를 링크했습니까?)

그건 사실입니다. 변경하기 전에는 계속 레이블이 지정된 정상적인 것이지만 동일한 문제가 존재한다고 생각합니다(그리고 나머지 루틴의 제어 흐름이 반환하는 값의 영향을 받을 수 있기 때문에 더 나쁠 수 있음).

@mark-im "액세스할 수 없기 때문에 기능을 사용하지 않음"은 "해당 기능에 액세스할 수 있도록 만드는 것"이 ​​아닙니다.

어떻게 우리가 레이블이 붙은 break를 조정하여 언어의 완전한 표현력을 얻을 수 있고 동시에 당신의 두뇌가 컴파일러뿐만 아니라 흐름 제어를 처리할 수 없다고 불평하는 것을 멈출 수 있습니까?

죄송합니다. 불평하려는 것이 아닙니다. 저만 이런 느낌이 든다면 한 발짝 물러나도 상관없습니다.

IMHO, 이것은 break/continue라는 레이블이 붙은 근본적인 문제입니다. 표현이 너무 _너무_ 하고, 이를 완화할 수 있는 유일한 방법은 "좋은 스타일"(그 의미가 무엇이든)로 권장 사용법을 사용하는 것입니다. 예를 들어, "루프 본문의 시작 또는 끝(중간이 아님)의 값이 있는 레이블이 붙은 break만 사용하십시오." 이는 값이 있는 루프를 종료하는 가능한 방법을 쉽게 찾아낼 수 있음을 의미합니다.

이것이 내가 다른 언어에서 goto/labeled break를 피하는 방법입니다: https://gist.github.com/SoniEx2/fc5d3614614e4e3fe131/#file -special-lua-L4-L72

그게 더 가독성이 좋나요?

그렇다면 레이블이 지정된 블록을 기반으로 하는 일종의 조건부 시스템을 알아낼 수 있을 것입니다. 마찬가지로 이 , 아마.

레이블이 지정되지 않은 break and continue의 요점은 루프 헤더에 조건/값을 쉽게 넣을 수 없는 경우를 제공하는 것입니다. 일부 루프는 중간에 중단이 있는 훨씬 더 간단하고 읽기 쉽고 빠릅니다.

반복문에서 break 및 continue라는 레이블이 지정된 요점은 유사합니다. 때로는 유일한 대안이 새 변수, 새 기능( return 남용)을 도입하는 것입니다. 불행히도 복잡한 레이블이 붙은 휴식이 있을 수 있습니다.

그러나 이 두 가지 기능은 이 스레드의 주제가 아닙니다. 그것들은 본질적으로 복잡한 제어 흐름을 표현하기 위해 제공하는 개선 사항 때문에 상당히 보편적입니다. 이 스레드는 대신 루프가 아닌 블록에서 벗어나는 것에 관한 것입니다. 이것은 확실히 더 새롭고 사람들은 루프 외부에서 break 를 찾는 것을 모를 수 있지만 레이블이 필요하다는 것은 의미를 알면 신호가 여전히 존재한다는 것을 의미합니다.

이것이 내가 귀하의 예에 대해 의미한 것입니다. @mark-im- 이는 레이블이 지정된 블록이 아니라 레이블이 지정된 루프 의 상당히 표준적인 사용이었습니다.

보다 "원칙적인" 접근 방식은 해당 블록의 값 값을 사용하여 블록 'a 이후' 즉시 실행을 계속하는 return 'value 구문을 사용하는 것입니다.

break 대 return 에 대한 참고 사항 : 정적 제어 흐름이기 때문에 break 선호합니다. return 는 동적이며 호출자에게 돌아갑니다. 호출자는 어디에나 있을 수 있습니다. "나는 내 책임을 다했고, 내가 하는 일을 볼 수 있는 다른 곳이 없다"는 의미입니다. break 는 루프와 마찬가지로 항상 어휘 범위에 있는 어딘가로 이동합니다.

내 생각 return 'label expr 이 '위치'라벨로 반환 EXPR "으로 간주 할 수있는"내가 무슨 말 "의 관점에서 정말 잘 읽습니다. 나는 break 'label expr 이 관점에서 똑같이 잘 읽히지 않는다고 생각합니다 ...

따라서 다른 프로그래밍 언어와 분리하여 return 'label expr 옹호했을 수 있습니다. 그러나 다른 언어의 제어 흐름을 고려할 때 return 재사용은 갑자기 실행 가능성이 훨씬 떨어지는 옵션이 되어 break 'label expr 를 선호하게 되었습니다.

나는 break 'label expr 가 아니라 return 'label expr 이어야 한다고 굳게 믿습니다. 그렇지 않으면 루프에서 기존의 break 'label 사용과 완전히 일치하지 않습니다.

@SoniEx2 나는 변수가 루프 불변성을 문서화하는 좋은 방법이기 때문에 게시한 스니펫을 선호한다고 생각합니다. OTOH, 레이블의 이름으로 동일한 작업을 수행하는 것이 가능할 수도 있습니다(즉, 이 레이블이 지정된 블록이 입력될 때마다 불변 P가 유지됨). 나는 이것이 야생에서 몇 가지 더 많은 코드 샘플을 갖는 것이 좋은 곳이라고 생각합니다 ...

안정화 제안

이 기능은 @est31에 의해 https://github.com/rust-lang/rust/pull/50045에 구현되었으며 2018-05-16(+17주) 이후 야간에 진행되어 안정화를 위해 충분히 구워졌습니다. 또한 이를 구현한 PR이 병합된 이후 보고된 문제는 없습니다. 그 이후로 해결되지 않은 모든 질문도 해결되었으며 return 대신 break 가 표면 구문이어야 한다는 강력한 합의가 있습니다.

따라서 레이블 구분 값(RFC 2046)을 안정화하기 위해 이동합니다.

@rfcbot 병합

보고서

• 기능 게이트:
  
  
  
  • https://github.com/rust-lang/rust/blob/master/src/test/ui/feature-gates/feature-gate-label_break_value.rs
  
  
  • https://github.com/rust-lang/rust/blob/master/src/test/ui/feature-gates/feature-gate-label_break_value.stderr
  
  
• 진단: https://github.com/rust-lang/rust/blob/master/src/librustc_passes/diagnostics.rs#L285
• 테스트:
  
  
  
  • https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_continue.rs
  
  
  • https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_unlabeled_break.rs
  
  
  • https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_illegal_uses.rs
  
  
  • https://github.com/rust-lang/rust/blob/master/src/test/ui/lint/unused_labels.rs
  
  
  • https://github.com/rust-lang/rust/blob/master/src/test/ui/run-pass/for-loop-while/label_break_value.rs
  
  

FCP 전에 할 일

@rfcbot 문제 FIXME-in-tests

마지막 테스트 파일 에는 현재 FIXME가 있습니다.

// FIXME: ensure that labeled blocks work if produced by macros and in match arms

안정화하기 전에 이 문제를 해결해야 합니다.
예상되는 동작이 제대로 작동하는지 확인하기 위해 몇 가지 테스트를 작성했습니다. FIXME는 실제로 구현됩니다.

// run-pass

#![feature(label_break_value)]

#[test]
fn lbv_match_test() {
    fn test(c: u8, xe: u8, ye: i8) {
        let mut x = 0;
        let y = 'a: {
            match c {
                0 => break 'a 0,
                v if { if v % 2 == 0 { break 'a 1; }; v % 3 == 0 } => { x += 1; },
                v if { 'b: { break 'b v == 5; } } => { x = 41; },
                _ => {
                    'b: {
                        break 'b ();
                    }
                },
            }
            x += 1;
            -1
        };

        assert_eq!(x, xe);
        assert_eq!(y, ye);
    }

    test(0, 0, 0);
    test(1, 1, -1);
    test(2, 0, 1);
    test(3, 2, -1);
    test(5, 42, -1);
    test(7, 1, -1);
}

#[test]
fn lbv_macro_test() {
    macro_rules! mac1 {
        ($target:lifetime, $val:expr) => {
            break $target $val;
        };
    }
    let x: u8 = 'a: {
        'b: {
            mac1!('b, 1);
        };
        0
    };
    assert_eq!(x, 0);
    let x: u8 = 'a: {
        'b: {
            if true {
                mac1!('a, 1);
            }
        };
        0
    };
    assert_eq!(x, 1);
}

// compile-fail

#![feature(label_break_value)]

fn lbv_macro_test_hygiene_respected() {
    macro_rules! mac2 {
        ($val:expr) => {
            break 'a $val;
        };
    }
    let x: u8 = 'a: {
        'b: {
            if true {
                mac2!(2);
            }
        };
        0
    };
    assert_eq!(x, 2);

    macro_rules! mac3 {
        ($val:expr) => {
            'a: {
                $val
            }
        };
    }
    let x: u8 = mac3!('b: {
        if true {
            break 'a 3;
        }
        0
    });
    assert_eq!(x, 3);
    let x: u8 = mac3!(break 'a 4);
    assert_eq!(x, 4);
}

제안된 FCP에서 FCP로 이동하기 전에 이와 유사한 테스트를 추가해야 합니다.

팀원 @Centril 이 이를 병합할 것을 제안했습니다. 다음 단계는 태그가 지정된 나머지 팀이 검토하는 것입니다.

• [x] @센트릴
• [x] @아투론
• [x] @cramertj
• [x] @eddyb
• [ ] @joshtriplett
• [x] @nikomatsakis
• [ ] @nrc
• [x] @pnkfelix
• [x] @scottmcm
• [ ] @보트 없이

우려 사항:

• 비용 편익 (https://github.com/rust-lang/rust/issues/48594#issuecomment-422235234)
• FIXME-in-tests (https://github.com/rust-lang/rust/issues/48594#issuecomment-421625182)
• 사용 사례(https://github.com/rust-lang/rust/issues/48594#issuecomment-422281176)

과반수의 검토자가 승인하고 반대하지 않으면 최종 의견 제출 기간이 시작됩니다. 이 프로세스의 어느 시점에서도 제기되지 않은 주요 문제를 발견하면 알려주세요!

태그가 지정된 팀 구성원이 나에게 줄 수 있는 명령에 대한 정보는 이 문서 를 참조하십시오.

@rfcbot은 비용-편익에 대해 우려합니다.

RFC FCP 제안에서 :

다른 그룹은 언어에 대한 이 기능의 "비용 이점"이 크게 줄어들지 않았다고 느꼈습니다. 다시 말해, 기능이 가져올 복잡성이 증가합니다. 다른 말로 하면 사람들이 실제로 이 기능을 사용하고 개발자가 코드를 읽고 언어의 전체 크기를 읽어야 할 가능성이 있다는 것입니다. 효용에 비례하지 않았다.

나는 여전히 우리가 이 기능을 가지고 있어야 한다고 생각하지 않습니다. 구현한 이후로 많이 사용되었나요? 이미 사용된 경우 기능을 사용하는 것이 훨씬 더 나쁘다? 여기에 이점이 있다면 언어를 더 크고 복잡하게 만드는 비용을 능가합니까?

@nrc 저도 같은

나는 원래 RFC 스레드에서 재생 타이어 인수 싶지 않아,하지만 문제는이 기능을 사용하여 경험에 대해 물어 적당한 시점이라고 생각하십니까. 그것은 어떤 용도를 보았습니까?

손으로 쓴 파서, 대부분... (나는 손으로 쓴 파서를 좋아한다 >.<)

레이블이 지정된 전파( try_foo() 'bar? )와 함께 사용하는 것이 더 유용하고 더 쉽습니다.

@rfcbot 관련 사용 사례

Discord에 대한 몇 가지 논의 요약: 실제 코드에서 이 기능을 사용하지 않도록 다시 작성할 때 더 명확하게 나타나지 않는 구체적인 사용 사례를 보고 싶습니다.

~FWIW, EXPR is PAT 구현 은 EXPR is PAT break 'label value 적어도 AST에서 사용할 수 있어야 합니다. 디슈가링이 없이는 어떻게 작동할 수 있는지 모르겠습니다.
구현 EXPR? 컴파일러는에 의존 break 'label value 뿐만 아니라. ~

~더 큰 제어 흐름 기능을 위한 일종의 기본 빌딩 블록이므로 어쨌든 컴파일러에서 구현해야 할 수 있습니다.
따라서 여기서 "비용"은 아마도 표면 구문에서 사용할 수 있게 하는 것입니다.~

편집: 문제를 완전히 잘못 해석했습니다. loop { ... break 'label value ... } { ... break 'label value ... } 블록이 아니라
나는 그것이 이미 구현되었다는 것을 항상 잊어버리기 때문에 이것을 시도할 기회가 없었습니다.

@petrochenkov Discord에서 @joshtriplett 와 대화하면서 그들은 언어 구현이 아니라 사용자가 직면하는 복잡성에 대해 걱정하고 있다고 지적했습니다.

복잡성 증가는 최소화된다고 생각합니다. 독자에게는 개념이 이미 루프 등에 존재하기 때문에 이것이 의미하는 바가 분명해야 합니다.
그렇지 않으면 조건부 break 문과 함께 루프를 사용해야 합니다. 이 명령문은 덜 명확하고 실제로 이것에 대해 클리피 보풀(never_loop)도 있습니다. 그래서 장점이 있는 것 같아요.

사용 사례에 관해서는 해당 주제가 이미 RFC에 올라왔습니다. 나는 여기 에서 나의 사용 사례 를 지적 했다 . 또한 바로 아래 @joshtriplett 는 사용 사례 질문을 해결합니까?

나는 @nrc 및 @joshtriplett에 동의하고 여기에 프로세스 문제를 제기하고 싶습니다. 우리는 @nrc 및 @joshtriplett 가 제기한 질문을 다시 방문할 때 안정화가 차단되었다는 명시적인 경고와 함께 이 RFC를 잠정적으로 수락했지만 @Centril은 병합 제안은 이 차단 문제를 전혀 언급하지 않으며 이것을 매우 표준적인 "기능이 구운" 병합으로 취급합니다. 이에 대해

차단 문제가 제기되지 않고 대부분의 팀 구성원이 이미 확인란을 선택한 상태에서 이것이 2일 반 동안 진행되었음을 확인하는 것은 전체 프로세스 측면에서 저에게 우려되었습니다. 더 이상 모든 구성원의 적극적인 합의가 필요하지 않기 때문에 차단기가 제기되지 않고 FCP에 들어갈 수 있다고 생각할 수 있습니다. 이것은 RFC 병합에 동의하게 만든 이전 계약의 전복처럼 느껴지며, 이는 전적으로 정보 추적이 불충분하기 때문이라고 생각합니다.

@withoutboats 네, 맞습니다. 이로 인해 앞으로는 "안정화 과정에서 XYZ가 될 것"이라는 원칙을 받아들이지 않으려는 경향이 있습니다. 그 과정에서 놓칠 가능성이 극히 낮은 일부 프로세스가 마련될 때까지입니다.

@withoutboats

이에 대해

그럼에도 불구하고 사과합니다. 주의 사항을 몰랐지만 추적 문제를 만들 때 그러한 사항을 확인했어야 했습니다.

이것은 RFC 병합에 동의하게 만든 이전 계약의 전복처럼 느껴지며, 이는 전적으로 정보 추적이 불충분하기 때문이라고 생각합니다.

나는 그것에 대해 해결되지 않은 질문을 했어야 했다. 나는 그 시점에서 프로세스 오류가 발생했다고 생각합니다.
프로세스를 개선하는 방법에 관해서는, 해결되지 않은 질문이 RFC의 _text_ 에

fcp-merge 제안에 관해서는; 나는 개인적으로 그것이 균일성과 매크로 사용을 위해 유용할 것이라고 생각합니다. 그러나 안정화를 제안하기에는 너무 이르다고 생각한다면; 제안을 취소해 주세요 :)

@est31

그렇지 않으면 무조건 break 문과 함께 루프를 사용해야 합니다.

또는 둘 중 하나를 피하기 위해 코드를 재구성하십시오.

나는 여기 에서 나의 사용 사례 를 지적 했다 .

break 'pseudo_return 를 return Ok(vectors); 않으시겠습니까?

여기 에서 언급했듯이 이것은 손으로 쓴 파서에 유용합니다(labeled-propagate( try_foo() 'bar? )가 없더라도).

label-break-value를 사용하면 다른 기능이 있는 코드를 쉽게 명령화할 수 있습니다. 일반적으로 명령형 코드는 기능적 코드보다 읽기 쉬운 경향이 있습니다.

또는 둘 중 하나를 피하기 위해 코드를 재구성하십시오.

물론 Rust는 완전한 튜링입니다. 그러나 구조조정은 다소 어려울 수 있다. 전반적으로 "기존 방식을 그대로 사용할 수 있음"을 기준으로 거의 모든 설탕 기능(이것이 설탕 기능)을 거부할 수 있습니다.

break 'pseudo_return을 return Ok(vectors);로 바꾸지 않는 이유는 무엇입니까?

실제로 이 경우 당신이 옳습니다. 휴식을 반환으로 바꿀 수 있습니다. Ok. 그러나 다른 경우에는 나중에 처리하는 등의 작업을 수행할 수 있습니다. 빌림 검사기는 함수 경계에서 제대로 작동하지 않으므로 이러한 블록을 하나의 함수로 인수분해할 수 없습니다.

어쨌든 공식적인 수단을 통해 언어 기능에 대해 언급하는 것에 대해 침묵을 깨고 tbh 후회하고 있습니다. 모든 동일한 점을 계속해서 다시 해시했습니다. 이 똥은 내 시간 낭비입니다, 죄송합니다. 그러니 저에게 더 이상의 코멘트를 기대하지 마십시오.

@est31 자세히 알려 주셔서 정말 감사합니다. 감사 해요.

야간 Rust의 요구 사항으로 인해 이러한 항목을 테스트하고 사용하는 데 접근성 문제가 있습니다.

안정을 목표로 합니다. 언젠가는 해결될 수 있기를 바랍니다.

사용 사례를 원하신다면 제가 얼마 전에 적중한 사례가 있습니다. 기본적으로 @est31 의 "나중에 처리 처리"의 정교함: C++ 문자열 리터럴 접두사를 처리하는 렉서를 작성했습니다(실제 C++의 경우 { L , u8 , u , U , }{ R , }) 및 사용된 바이트 수에 "갭"이 있는 다중 바이트 토큰(다음 없이는 의미가 확실하지 않음 예). get_token 함수는 현재 다음과 같습니다.

fn get_token(&mut self) -> Token {
    match decode_byte(self.source) {
        // ...

        // repeat four times with small variations for b'U', b'L', and b'R':
        Some((b'u', rest)) => match decode_byte(rest) {
            Some((b'"', rest)) => self.string_literal(Utf16String, rest),
            Some((b'\'', rest)) => self.char_constant(Utf16Char, rest),
            Some((b'R', rest)) => match decode_byte(rest) {
                Some((b'"', rest)) => self.raw_string_literal(Utf16String, rest),
                _ => self.identifier(rest),
            },
            Some((b'8', rest)) => match decode_byte(rest) {
                Some((b'"', rest)) => self.string_literal(Utf8String, rest),
                Some((b'\'', rest)) => self.char_constant(Utf8Char, rest),
                Some((b'R', rest)) => match decode_byte(rest) {
                    Some((b'"', rest)) => self.raw_string_literal(Utf8String, rest),
                    _ => self.identifier(rest),
                },
                _ => self.identifier(rest),
            },
            _ => self.identifier(rest),
        },

        // ...

        // the "gap" mentioned above is here: single-byte '.' and triple-byte '...' but no double-byte '..':
        Some((b'.', rest)) => match decode_byte(rest) {
            Some((b'0'..=b'9', rest)) => self.number(rest),
            // note the _inner to avoid shadowing the outer `rest` used by the inner `Dot` case:
            Some((b'.', rest_inner)) => match decode_byte(rest_inner) {
                Some((b'.', rest)) => self.make_token(Ellipsis, rest),
                _ => self.make_token(Dot, rest),
            },
            _ => self.make_token(Dot, rest),
        },

        // ...
    }
}

_ => self.identifier(rest) s ( u , U , R , L 대해 네 번 반복됨) 및 _ => self.make_token(Dot, rest) 의 피라미드를 확인하십시오 U _ => self.make_token(Dot, rest) s, identifier , string_literal 등은 모두 make_token 도 호출해야 하는 일종의 연속 전달 스타일을 형성합니다.

break -from-block을 사용하여 덜 연속적인 스타일로 다시 통합하고 싶었고 loop 레이블을 통해 거의 그렇게 했지만 해당 버전은 읽기에 너무 이상하다고 생각했습니다. 더 구체적으로:

• 나는 모든 make_token 호출을 기본 match decode_byte(self.source) 다음의 단일 위치로 이동하고 인라인했습니다. get_token 의해 유지되는 불변과 함께 작고 unsafe 를 포함합니다. get_token .
• break 'label self.string_literal(..) 를 사용하여 " 또는 ' 를 찾은 다음 모든 self.identifier(..) 호출을 해당 매치 암의 끝까지 결합했습니다. .
  
  
  
  • 또한 접두사의 조합 폭발을 선형화할 수 있었을 수도 있습니다. u / u8 / U / L 를 확인한 R 을 확인하십시오. R . 이것은 더 적은 수의 break 'label 를 사용하지만 여전히 소수입니다.
  
  
• break 'label (Ellipsis, rest) 를 사용하여 ... 를 찾은 다음 두 (Dot, rest) 를 해당 매치 암의 끝에 결합했습니다.

전체적으로 이것은 별도의 기능으로 항목을 추출할 필요가 없는 기본적으로 "if + 조기 반환을 사용한 평면 제어 흐름"입니다. 이 경우 다음과 같은 몇 가지 이유로 매우 중요합니다.

• 이러한 함수의 대부분은 이름이 좋지 않은 작은 일회용 함수로, 이 연속 스타일보다 가독성이 떨어지게 만들 뿐입니다.
• 이러한 함수 중 일부는 유추된 유형이 있는 간단한 로컬일 수 있는 많은 추가 매개변수를 필요로 합니다.
  
  
  
  • 또는 이러한 경우에 대출 검사기 문제를 일으킬 수 있는 폐쇄입니다.
  
  
• 위에서 언급했듯이 여기에서는 기능 전반에 걸쳐 안전 불변성이 유지됩니다. 여기서 더 직선적이고 상태 기계적인 코드가 더 좋습니다. 특히 사람들이 나중에 돌아와서 새로운 토큰 유형에 대해 약간의 변경을 가할 때 더 좋습니다.

나는 모든 것을 쓸 것이지만 나는 그런 시도를 한 적이 없다고 생각합니다(아마도 내가 위에 나열한 모든 문제에 부딪쳤기 때문일 것입니다). 그리고 이미 여기에 충분한 단어를 썼습니다. :)

@SergioBenitez http://rocket.rs/ 의 label_break_value 사용법과 안정화에 대한 귀하의 견해에 대해 자세히 설명해 주 시겠습니까?

@센트릴 맞아요 ! 요지는 다음과 같습니다.

fn transform(request: &Request, data: Data) -> Transform<Outcome<_, _>> {
    let outcome = 'o: {
        if !request.content_type().map_or(false, |ct| ct.is_form()) {
            break 'o Forward(data);
        }

        let mut form_string = String::with_capacity(min(4096, LIMIT) as usize);
        if let Err(e) = data.read_to_string(&mut form_string) {
            break 'o Failure(FormDataError::Io(e));
        }

        Success(form_string)
    };

    Transform::Borrowed(outcome)
}

이 기능을 사용하면 다음을 피할 수 있습니다.

• 조기 "반환"을 위해 블록을 다른 기능으로 분할.
• 블록의 모든 "반환" 값에 Transform::Borrowed 추가.
• 다른 경우에 다른 Transform 가 반환되는 경우 부정확할 수 있습니다.
  
  
  
  • 참고: 이것은 Rocket과 이 코드 조각에 특정한 불변입니다.
  
  

이것이 존재한다는 사실에 나는 꽤 기뻤다. 이것이 바로 제가 쓰고 싶은 것입니다. 즉, 이 기능에 의존하지 않기 위해 이것을 다르게 작성할 수 있습니다.

@SergioBenitez 감사합니다! 나는 이것을 try { .. } (결국) 다시 작성할 수 있는지 궁금합니다. 이렇게:

fn transform(request: &Request, data: Data) -> Transform<Outcome<_, _>> {
    Transform::Borrowed(try {
        if !request.content_type().map_or(false, |ct| ct.is_form()) {
            Forward(data)?;
        }

        let mut form_string = String::with_capacity(min(4096, LIMIT) as usize);
        if let Err(e) = data.read_to_string(&mut form_string) {
            Failure(FormDataError::Io(e))?;
        }

        form_string
    })
}

@Centril 예, 성공 경로가 하나만 있는 한 작동합니다. 여기에 해당합니다.

또는 둘 중 하나를 피하기 위해 코드를 재구성하십시오.

이렇게 하면 최적화 프로그램에서 해결할 수 없는 추가 분기 또는 서브루틴 호출을 추가할 위험이 있습니다. 나에게 이러한 제어 흐름 변환은 상당히 복잡한 작업으로 보입니다.

이미 사용된 경우 기능을 사용하는 것이 훨씬 더 나쁘다? 여기에 이점이 있다면 언어를 더 크고 복잡하게 만드는 비용을 능가합니까?

작은 함수가 인라인될 수 있지만 그럼에도 불구하고 불필요한 코드 팽창 또는 어리석은 코드 중복을 얻을 수 있습니다.

나는 가능한 가장 우아한 바이너리 코드를 선호합니다. 함수에서 일찍 복귀하는 것과 거의 동일한 좀 더 고급 제어 흐름으로 이를 수행할 수 있습니다.

나는 이것을 try { .. }로 (결국) 다시 작성할 수 있는지 궁금합니다. 이렇게:
[...]

최적화를 위해 분기가 도입될 때 약간 혼란스러워 보입니다. 그러나 어떤 상황에서는 둘 다 필요할 수 있습니다. 따라서

'a: {try{...}}

또는

'a: try {...}

좋은 것.

이 기능을 사용하지 않도록 다시 작성할 때 더 명확하게 나타나지 않는 실제 코드에서 이에 대한 구체적인 사용 사례를 보고 싶습니다.

저를 욕되게 해주십시오.

• operator_mul
• operator_get
• 메인 루프

최고의 코드는 아니지만 모든 것이 제대로 작동하기를 원했습니다.

연속 전달 스타일의 관점에서 메인 루프를 상태 머신으로 실험적으로 다시 설명하고 싶습니다. 그러나 연속 및 강제 꼬리 호출은 또 다른 주제입니다.

야생에서 찾은 몇 가지 용도를 버리십시오.

• https://github.com/veloren/game/blob/12693916bc1f1620418f9cb18909b9f55875dbb3/server/src/msg.rs
• https://github.com/veloren/game/blob/8e4ddbeba89eb964d6939664414a68c9bb929968/client/src/world.rs
• https://github.com/Laaas/abstract-struct/blob/d8f52bc982aceef6a7bd4a07c6f776a12880e80b/macro/lib.rs
• https://github.com/71/rust-version-macro/blob/bc381d688a642e851e84fe4b05c38288489b227c/src/lib.rs

이 기능이 안정화되면 매우 좋을 것입니다. 이 구문이 의도를 크게 단순화하고 명확하게 하는 많은 사용 사례가 있습니다. 오류가 있는 작업을 수행하고 결과를 래핑 해제하는 긴 섹션의 경우 이 구문이 탁월합니다.

이 기능의 안정화가 생태계에 도움이 되고 특정 패턴을 작성하는 데 덜 귀찮게 만든다는 @zesterer의 의견에 동의합니다.+1:

FWIW, 최근에 컴파일러에서 처음으로 사용했습니다.
패턴은 이전 예와 동일합니다. 여러 조건을 확인하고 그 중 하나라도 참이면 하던 일을 멈춥니다.
https://github.com/rust-lang/rust/blob/21f26849506c141a6760532ca5bdfd8345247fdb/src/librustc_resolve/macros.rs#L955 -L987

@erickt 는 또한 같은 이유로 이것을 사용하려는 몇 가지 코드를 작성했습니다. 여러 조건을 확인하고 그 중 하나가 거짓이 되면 중단합니다. 즉시 호출된 클로저 또는 let _: Option<()> = try { ... None?; .. }; 로 이것을 속일 수 있지만 둘 다 꽤 해키합니다.

@withoutboats @nrc @joshtriplett 지금까지 다양한 사람들이 제시한 사용 사례에 대한 생각이 있습니까?

Ping @withoutboats @nrc @joshtriplett :) -- 지난 회의에서 우리는 여러분이 위에 주어진 몇 가지 예를 다시 작성하고 어떻게 구성할지 보여줄 가능성에 대해 논의했습니다.

나는 이 기능을 안정화하고 싶지 않은 이유에 대한 의견을 여기에 작성 하려는 greydon의 블로그 게시물 에 자극을

내 전반적인 반대는 단순히 Rust가 더 많은 개방형 분기 제어 흐름 구성을 필요로 하지 않는다고 생각한다는 것입니다. 매치와 루프, 그리고 이러한 대수적 데이터 유형, 구문 설탕, 함수 추상화 및 매크로를 사용하여 일반 사용자가 처리할 수 있는 제어 흐름 패턴의 거대한 배열을 만듭니다. 이것은 이미 압도적으로 바뀌는 것처럼 느껴지며 개인적으로 의사 결정 트리의 복잡성을 관리하기 위해 몇 가지 규칙을 채택해야 했습니다(예를 들어, 첫 번째 패스로 결합자를 사용하지 않는 규칙이 있습니다. 사실 그것은 결합자로 더 좋을 것입니다).

Rust의 제어 흐름 도구 상자에 더 광범위하게 적용할 수 있고 매우 유연한 선택 항목을 추가하는 것을 피하고 싶습니다. 저는 특정하고 중요한 사용 사례를 대상으로 하고 인체 공학적인 영향이 높은 제어 흐름을 추가하는 데만 관심이 있습니다. 내 생각에 이 구성은 정확히 반전된 속성을 가지고 있습니다. 즉, 광범위하게 적용할 수 있고, 극도로 가독성이 높으며, 대안보다 약간 더 편리합니다.

게다가 이 기능에는 또 다른 부정적인 특성이 있다고 생각합니다. 하위 호환성으로 인한 불규칙성입니다. break 가 레이블이 지정되지 않은 루프에서 벗어날 때 레이블이 지정된 경우에만 블록에서 이탈하는 것은 매우 불규칙합니다. 이것은 기능을 일반 경우보다 이해하기 어렵게 만들고, 내가 생각하는 최악의 위치인 이해도에서 부정적인 속성을 악화시킵니다.

또한 집중해야 할 훨씬 더 중요한 기능이 많이 있다고 생각하며, 이에 대해 명확한 의견 차이가 있기 때문에 이 제안에 대해 긴 합의 과정을 거치기보다는 검토를 연기하는 것이 좋습니다.

이 기능을 사용하는 모든 크레이트를 찾아서 이 기능을 사용하지 않도록 코드를 다시 작성하는 것이 옳다고 생각합니다.

@withoutboats 저 와 같은 반대 의견을 매우 효과적으로

저는 여기서 과감하게 진행하겠습니다.

@rfcbot 취소
@rfcbot 연기

@joshtriplett 제안이 취소되었습니다.

팀원 @joshtriplett 가 연기를 제안했습니다. 다음 단계는 태그가 지정된 나머지 팀이 검토하는 것입니다.

• [ ] @센트릴
• [ ] @아투론
• [ ] @cramertj
• [ ] @eddyb
• [x] @joshtriplett
• [ ] @nikomatsakis
• [ ] @nrc
• [ ] @pnkfelix
• [ ] @scottmcm
• [x] @withoutboats

현재 나열된 우려 사항이 없습니다.

과반수의 검토자가 승인하고 반대하지 않으면 최종 의견 제출 기간이 시작됩니다. 이 프로세스의 어느 시점에서도 제기되지 않은 주요 문제를 발견하면 알려주세요!

태그가 지정된 팀 구성원이 나에게 줄 수 있는 명령에 대한 정보는 이 문서 를 참조하십시오.

@withoutboats

Rust의 제어 흐름 도구 상자에 더 광범위하게 적용할 수 있고 매우 유연한 선택 항목을 추가하는 것을 피하고 싶습니다. 저는 특정하고 중요한 사용 사례를 대상으로 하고 인체 공학적인 영향이 높은 제어 흐름을 추가하는 데만 관심이 있습니다.

나는 이 원칙에 동의하며 이 기능이 그 기준을 충족한다고 생각합니다(특정하고 중요한 사용 사례를 대상으로 하는 친숙한 제어 흐름). 위에 제공된 예제와 같은 코드를 검토하거나 작성했을 때 이것이 이 코드를 작성하는 가장 깔끔하고 읽기 쉬운 방법이라고 생각하는 경우가 여러 번 있습니다. loop 와 같은 기존 제어 흐름 구조를 끝에 무조건 break loop 과 함께 재사용하면 사용자가 오도되고 ? , await! 사용으로 인해 즉시 적용되는 기능이 부족한 경우가 많습니다

loop + 후행 break 것은 혼란스럽고 사용자가 다른 스타일의 제어 흐름을 위해 만들어진 도구를 남용하도록 요구하는 것보다 실제 의도를 진술하게 하는 것을 선호해야 합니다. 이것은 우리 가 loop 구조를 가지고 있다는 사실과 유사하지만 다른 언어는 while true { ... } 합니다. 이렇게 하면 더 명확한 의도를 표현하고 결과적으로 더 읽기 쉬운 코드를 작성할 수 있습니다.

추가로, 이 기능은 우리가 레이블이 붙은 대부분의 다른 것들과 레이블이 지정된 것들에서 벗어나는 것을 감안할 때 Rust가 가질 것으로 항상

TL;DR: 이 기능은 많이 중첩된 if 문을 통해 또는 루프 중단 값과 같은 다른 구성을 남용함으로써만 달리 작성할 수 있는 실제 사용 사례를 지원한다고 생각합니다. 블록이 내가 예상하는 대로 동작하도록 하는 표면 구문에 대한 작은 추가 사항이며 훨씬 더 해커가 아닌 내가 의미하는 코드를 작성할 수 있도록 합니다.

@cramertj 죄송합니다. 약간 혼란스럽습니다. 당신과 @withoutboats / @joshtriplett 가 서로 정반대의 말을 하는 것

(fwiw, @withoutboats /@joshtriplett에 동의합니다)

@mark-im 이 기능을 닫아야 한다는 의견에 동의하지 않습니다. 나는 그것이 병합되어야한다고 생각합니다 (내 의견과 위의 확인란으로 표시됨).

나는 우리가 특정하고 중요한 사용 사례에 의해 동기가 부여되지 않은 새로운 익숙하지 않은 도구를 추가해서는 안된다는 @withoutboats에 동의합니다. 나는 이 기능 이 친숙 것이며 구체적이고 중요한 사용 사례에 의해 동기가 부여

@withoutboats

나는 이 실험에 동의한 것이 약간 불공평하다고 생각합니다. 부정을 증명하기는 어렵지만 어떤 종류의 코드 샘플이 언어에 이러한 형태의 제어 흐름을 추가하는 것에 대한 반대를 극복할 수 있는지 전혀 모릅니다.

저는 우리가 설정한 기준이 "label-break-value로 더 잘 작성할 수 있는 코드가 존재하지 않는다는 것을 보여주십시오"라고 생각하지 않습니다. 그것은 "label-break-value를 원하는 특정 코드가 더 명확하게 다른 방법으로 작성되었습니다." 이 대화는 당신과 다른 사람들이 이 기능이 어디에 유용한지 동기를 부여하는 예를 요청했을 때 시작되었으며 이 스레드의 많은 사람들(저를 포함하여)이 예를 제공했습니다. 그들은 당신이나 @joshtriplett 에게 설득력이 없었

저는 여기서 과감하게 진행하겠습니다.

@rfcbot 취소

@scottmcm 제안이 취소되었습니다.

레이블이 지정되지 않은 루프에서 벗어날 때 레이블이 지정된 경우에만 break가 블록에서 이탈하는 것은 매우 불규칙합니다.

스레드에서 언급되었는지 여부는 확실하지 않지만 break; 의해 대상이 지정되지 않는 블록은 레이블이 지정된 블록을 어떤 의미에서 레이블이 지정된 loop 보다 질적으로 더 강력합니다.

레이블이 지정된 블록을 사용하면 내부에서 break; 를 지원하는 제어 흐름 매크로를 만들 수 있으며 매크로 인프라는 사용자에게 완전히 보이지 않습니다.
레이블이 있는 루프를 사용하면 레이블이 없는 break; 가 사용되어 의도한 대상이 아닌 매크로 인프라에 포착될 위험이 항상 있습니다.

내 EXPR is PAT 프로토타입에서는 초기에 디슈가링을 위해 일반적인 loop 했지만 앞서 언급한 문제로 인해 문제가 발생하여 특히 컴파일러를 부트스트랩할 수 없었습니다.
그 당시에는 레이블이 지정된 블록이 구현되지 않았기 때문에 AST에 특별한 "untargetable loop "를 도입하고 디슈가링에 사용해야 했습니다.

내 확인란에 표시된 대로 지금은 안정화에 찬성합니다. 나는 이것이 매크로와 기능적 패턴에 쉽게 맞지 않는 제어 흐름을 용이하게 하는 언어의 자연스러운 확장이라고 생각합니다. NLL이 수명을 어휘가 아닌 것으로 만들더라도 수명이 있는 블록에 주석을 추가할 수 있다는 것은 type ascription과 마찬가지로 교육학적으로 도움이 된다고 생각합니다.

그러나 합의를 달성하기 어려웠기 때문에 합의를 찾는 데 관심이 있으므로 try { ... } 에 대한 작업의 속도를 높이고 https://github.com 을 사용한 실험 작업의 속도를 높이는 것이 좋습니다. @petrochenkov 의 EXPR is PAT 구문과 동시에).

죄송합니다. 지금 상태가 어떻습니까? 우리는 FCP에 있습니까?

@mark-im proposed-final-comment-period 또는 final-comment-period 레이블 중 어느 것도 문제에 있지 않기 때문에 우리는 FCP나 이에 대한 제안에 참여하지 않습니다.

(그리고 우리는 FCP에 한 번도 가본 적이 없지만 세 개의 확인란을 제외한 모든 항목을 선택하여 FCP에 입장하겠다는 초기 제안이 있었지만)

@scottmcm

저는 여기서 과감하게 진행하겠습니다.

@joshtriplett 의 이 반복적인 표현은 매우 냉소적이었습니다. lang 팀의 일원으로서 다른 기여자들과 의사소통하는 방법에 대해 신중하게 생각하십시오.

나는 이것이 사실 좋은 생각이라고 확신합니다. 나는 이전에 이 기능에 대해 매우 반대했으며 여전히 이것이 프로그래머가 사용해서는 안 되는 기능이라고 생각하지 않습니다. 위의 사용 사례는 다소 설득력이 있지만 더 작은 기능에 더 잘 통합될 수 있다고 생각합니다. 내가 정말 설득력 있게 찾은 경우는 매크로의 출력입니다. 사용자가 return 어떤 방법으로 삽입할 수 있다면 이것은 함수로의 변환을 배제합니다. 그러나 우리가 정말로 원하는 것은 평범한 goto 입니다. '큰' 솔루션이 토큰이 아닌 HIR을 출력할 수 있는 매크로인지 궁금합니다. 그 동안 매크로 작성자에게 이 기능이 있으면 좋을 것이므로 균형을 맞춰 안정화해야 한다고 생각합니다.

누구든지 느리고 덜 직관적이며 덜 인체 공학적인 방식으로 다시 작성하려고 시도한 적이 있습니까?

블록을 깨는 것은 인체공학적 goto와 같습니다. goto의 문제는 거의 없지만 강력합니다.

@nrc 님 의 마음의 변화를 바탕으로 label_break_value 안정화를 위해 또 움직입니다.
내 보고서는 https://github.com/rust-lang/rust/issues/48594#issuecomment -421625182에서 찾을 수 있습니다.

@rfcbot 병합
@rfcbot 문제 FIXME-in-tests

@joshtriplett 및 @withoutboats 가 여전히 갖고 있는 우려 사항을 제기할 시간을 가질 수 있도록 그러한 우려 사항을 기록하겠습니다. 나는 그들이 그러한 우려가 없다고 말하거나 그들 중 한 명이 자신의 우려를 제기하면 해제하겠습니다.

@rfcbot 은 여전히 ​​가지고 있을 수 있는 우려 사항을 제기할 시간을 줄 수 있습니다.

이 문제와 다른 모든 문제에 대한 프로세스 참고 사항으로, 제안을 취소하고 왔다갔다 하지 마세요... 앞으로 진행해야 할 사항이 없다고 생각되면 우려 사항을 사용하세요.

팀원 @Centril 이 이를 병합할 것을 제안했습니다. 다음 단계는 태그가 지정된 나머지 팀원이 검토하는 것입니다.

• [x] @센트릴
• [x] @아투론
• [x] @cramertj
• [x] @eddyb
• [x] @joshtriplett
• [ ] @nikomatsakis
• [ ] @nrc
• [x] @pnkfelix
• [ ] @scottmcm
• [ ] @보트 없이

우려 사항:

• 차단(https://github.com/rust-lang/rust/issues/48594#issuecomment-451673194)
• FIXME-in-tests (https://github.com/rust-lang/rust/issues/48594#issuecomment-451672226)
• Give-boats-and-josh-time-to-raise-any-concerns-they-might-still-have 는 https://github.com/rust-lang/rust/issues/48594#issuecomment -451673282에 의해 해결되었습니다.
• should-close-not-merge 는 https://github.com/rust-lang/rust/issues/48594#issuecomment -632960804로 해결되었습니다.

과반수 이상의 검토자가 승인하면(최대 2개의 승인이 미결 상태임) 최종 의견 수렴 기간이 시작됩니다. 이 프로세스의 어느 시점에서도 제기되지 않은 주요 문제를 발견하면 알려주세요!

태그가 지정된 팀 구성원이 나에게 줄 수 있는 명령에 대한 정보는 이 문서 를 참조하십시오.

@rfcbot 우려 차단

저는 이미 Rust에 이 기능이 없어야 한다는 제 입장을 밝혔습니다. 가까운 시일 내에 이 제안에 대한 합의에 도달하는 프로세스에 참여하는 데 시간을 할애할 수 있는 프로젝트의 우선 순위가 충분히 높은지 의심됩니다.

@rfcbot 해결

중요하다면: Zig에도 이 기능이 있습니다 .

2019년 1월 5일 오전 9:18:29 PST, Mazdak Farrokhzad [email protected] 은 다음과 같이 썼습니다.

@rfcbot 해결
그들은 여전히 ​​가지고 있을지도 모르는 우려를 제기할 시간을 주고

우리는 이미 우려를 제기했으며 "이것은 언어로되어서는 안됩니다"에 달합니다. 그런 걱정이 사라지지 않습니다.

매크로가 IR을 생성할 수 있어야 한다는 nrc의 개념을 선호합니다. 이것은 언어의 표면 구문에 반드시 추가하지 않고도 이것과 미래의 많은 가능성에 대해 완전히 합리적인 솔루션처럼 보입니다.

@joshtriplett

우리는 이미 우려를 제기했으며 "이것은 언어로되어서는 안됩니다"에 달합니다. 그런 걱정이 사라지지 않습니다.

명확히 하자면 제안이 취소된 후 봇이 등록된 이전 우려 사항을 볼 수 없기 때문에 @rfcbot 등록하는 것을 의미했습니다. 우려 사항이 있다는 것을 알고

매크로가 IR을 생성할 수 있어야 한다는 nrc의 개념을 선호합니다. 이것은 언어의 표면 구문에 반드시 추가하지 않고도 이것과 미래의 많은 가능성에 대해 완전히 합리적인 솔루션처럼 보입니다.

나는 그것이 어떻게 생겼는지 또는 그것이 더 나은 아이디어인지 전혀 모릅니다. 매크로의 결과가 아닌 이점이 있는 break 'label expr 의 다소 저렴한 솔루션보다 다소 투기적이며("이것은 디자인이 동의되기까지 몇 년이 걸릴 수 있음"이라는 의미에서) 비용이 많이 듭니다. 확장.

_이 문제와 다른 모든 문제에 대한 프로세스 참고 사항으로, 제안을 취소하고 왔다 갔다 하지 마세요... 앞으로 진행해야 할 사항이 없다고 생각되면 우려 사항을 사용하세요._

나는 확실히 그것에 동의합니다. 그러나 여기에서 적절한 메커니즘이 문제라고 생각하지 않습니다. 우려는 "이 문제가 해결되면 승인하겠습니다"와 같습니다. 여기서 문제는 "이것은 전혀 진행되어서는 안되며 '병합'이 잘못된 대상입니다. 대신 '닫기'를 원합니다." 그것은 "우려"라는 메커니즘으로 가장 잘 처리되지 않는 것 같습니다.

@joshtriplett 관심 있는 부분으로, 이전에 언급한 문제에 대해 말씀해 주시겠습니까? 원래 RFC 스레드를 살펴보았고 구체적으로 무엇을 언급하는지 잘 모르겠습니다. 감사 해요.

@rfcbot은 인체 공학 및 최적화/성능에 대해 우려합니다(성능 및 인체 공학 감소의 녹슬지 않는 예 https://gist.github.com/SoniEx2/fc5d3614614e4e3fe131#file-special-lua )

이 권리를 사용하고 있다면 idk

(일부 "디슈가링"(사실 나는 그것이 디슈가링의 반대라고 말하고 싶습니다 - goto는 원시적이며, desugar를 goto로 반복함)이 매우 끔찍합니다)

(또한 루아에는 레이블이 지정되지 않은 항목이 없으므로 goto를 사용해야 합니다. 그런 경우에도 최소한 하나의 break-block이 여전히 필요하지만 아마도 더 깨끗한 "디슈가링"이 필요할 것이라고 생각합니다.)

@rfcbot 문제는 병합하지 말아야 합니다.

(Discord에서 @centril이 제안한 대로)

이것이 안정화에 대한 찬성인지 반대인지 확실하지 않지만 오늘날 안정적인 Rust에서 인코딩하기가 매우 쉽다는 점에 유의하세요.

fn main() {
    'foo: for _ in 0..1 {
        println!("break");
        break 'foo;
        println!("broken");
    }
}

따라서 한편으로는 for _ in 0..1 만 생략하고 언어가 거의 성장하지 않기 때문에 이것을 안정화해야 합니다. 다른 한편으로는 오늘날 쉽게 할 수 있는 방법이 있기 때문에 안정화해서는 안 됩니다. 그것은 정말로 필요합니다) 그리고 우리는 그러한 안티 패턴을 사용하도록 조장해서는 안됩니다.

그것은 다소 혼란스럽고 레이블이 필요하지 않습니다.

블록을 깨는 것은 훨씬 덜 혼란스럽고 레이블이 필요합니다.

왜 블록을 깨는 것이 반패턴이라고 생각하는지 이해가 되지 않습니다. X에 적용되는 것이 반드시 not-quite-X에 적용되는 것은 아닙니다. 나는 컴퓨터를 299.99달러에 살 수 있지만 299.98달러는 살 수 없다. 비록 "기본적으로" 똑같더라도 말이다.

@nrc

이것이 안정화에 대한 찬성인지 반대인지 확실하지 않지만 오늘날 안정적인 Rust에서 인코딩하기가 매우 쉽다는 점에 유의하세요.

    'foo: for _ in 0..1 {
        break 'foo;
    }

따라서 한편으로는 for _ in 0..1 생략하고 언어가 거의 성장하지 않기 때문에 이것을 안정화해야 합니다.

'a: for _ in 0..1 { break 'a } 는 명시적인 목표가 'a: { ... break 'a e; ... } 쓰지 못하도록 하는 것이라면 작동할 수 있습니다. 그러나 유형 검사기, MIR 및 LLVM이 처리해야 하는 가비지 IR을 생성하여 컴파일 시간을 악화시키는 단점이 있습니다(최소한 LBV에 비해).

반면에 우리는 이것을 안정화해서는 안 됩니다. 왜냐하면 오늘날 쉽게 할 수 있는 방법이 있기 때문입니다(정말 필요한 경우). 그리고 우리는 그러한 안티 패턴을 사용하도록 권장해서는 안 됩니다.

저는 LBV가 반패턴이라는 데 동의하지 않는다고 생각합니다. 결국 우리는 Rust를 함수형 프로그래밍 언어로 만드는 대신에 명령형 제어 흐름을 Rust에 주입하기로 결정했습니다. 그러한 제어 흐름이 없는 것을 선호했을 수도 있지만 이는 당연한 일입니다. 문제는 LBV가 Rust의 다른 명령적 메커니즘보다 더 읽기 어렵거나 문제가 있는지 여부입니다. 그렇지 않다고 생각합니다.

함수는 짧고(세로) 얕게(들여쓰기) 유지해야 한다고 생각하지만 길고 얕은 것보다 길고 얕은 것이 좋습니다. 나는 LBV가 좀 더 복잡한 흐름의 깊이를 피하는 데 도움이 된다는 것을 알게 되었습니다. LBV는 이동할 위치를 명시적으로 나타내므로 흐름을 잘 이해할 수 있도록 하기 때문에 LBV도 읽을 수 있는 것 같습니다. 대체로 LBV는 문제가 가장 적은 명령형 제어 흐름 중 하나입니다.

1. 'a: for _ in 0..1 { break 'a }
2. 'a: { ... break 'a e; ... }

이것들은 비슷해 보이지만 완전히 같지는 않습니다. 첫 번째는 틀림없이 반패턴이지만 두 번째는 틀림없이 아닙니다.

loop {} 대 while true {} 와 비슷합니다( loop 는 값을 반환할 수 있지만 while 는 반환할 수 없지만 잠시 무시합시다)

@nrc 그래도 동일한 동작은 없습니다. https://github.com/rust-lang/rust/issues/48594#issuecomment -450246249

특히 break; 및 continue; 은 다릅니다. 다음 가상 코드를 고려하십시오.

some_macro! {
   ...
   break;
   ...
}

some_macro 가 'a { ... } 확장되면 'a: for _ 0..1 { ... } 확장할 때와 다른 동작을 합니다.

@SoniEx2

누구든지 느리고 덜 직관적이며 덜 인체 공학적인 방식으로 다시 작성하려고 시도한 적이 있습니까?

좀 더 긍정적이고 생산적인 방법으로 문제를 통신을 시도하십시오. 다른 사람들을 조롱하는 것은 우리를 어디에도 데려가지 않으며 사람들을 기분 나쁘게 만듭니다. 우리는 Rust가 가능한 최고의 프로그래밍 언어임을 확인하고 커뮤니티가 가능한 한 긍정적이고 고무적인지 확인하기 위해 여기 있습니다.

아마도 내가 큰 오해를 하고 있는 것 같습니다. 나는 LLVM, Rust의 내부 또는 이와 유사한 것들의 전문가인 척하지 않을 것입니다. 즉, 컴파일러 설계에 대한 기본적인 경험이 있으며 우려 사항이 무엇인지 혼란스럽습니다. 누군가 설명할 수 있다면 정말 감사하겠습니다.

내가 사물을 보는 방식:

1) 이것은 흐름 제어의 인체 공학을 변경하지 않습니다. 'a: loop { if x { break 'a; } break; } 와 같은 Rust에는 이미 이와 같은 구조가 존재합니다.

2) 이것은 특히 블록 반환의 인체 공학을 변경하지 않습니다. 루프는 이미 값을 반환할 수 있습니다.

나에게 이것은 Rust가 이미 가지고 있는 기능 세트를 직관적으로 완성하는 것처럼 보입니다. 이러한 기능을 모든(또는 적어도 더 많은) 블록에 대해 일반화하는 것입니다.

이것이 goto 와 너무 유사하다는 점에서 저는 더 혼란스럽습니다. 이것은 Rust에서 이미 가능하지 않은 것을 추가하지 않으며 역방향 점프( goto 가 스파게티 코드로 회귀하는 잘못된 사용을 초래하는 주요 문제)를 허용하지 않으므로 실패하고 있습니다. 이 기능이 codegen에 어떤 영향을 미칠 수 있는지 이해하려면 이것이 항상 중단되는 루프에 대한 구문 설탕인 것처럼 보이기 때문입니다.

어떤 문제가 있는지 좀 더 구체적으로 설명해줄 수 있는 사람이 있습니까?

절차상 IMO concern blocking 또는 concern should-close-not-merge 스타일 문제를 제출하는 것은 적절하지 않습니다. 이 문제는 제안된 기능의 문제나 해결을 위해 노력할 수 있는 문제를 나열하지 않습니다. - 그냥 영구 차단입니다. 나는 rfcbot의 우려 메커니즘이 기능을 영구 차단하는 데 사용되어야 한다고 생각하지 않습니다. 단지 우려의 해결을 추적하고 적절하게 해결/해결되도록 하는 데 도움이 될 뿐입니다. 프로세스에 대한 나의 이해는 체크되지 않은 체크박스를 사용하여 동의하지 않음을 표시하는 것이며 우려 사항은 기능 및 해당 기능에 대해 논의할 수 있는 특정 문제를 제출하는 데 사용된다는 것입니다.

개인적으로 동의하지 않는 다른 기능(예: uniform_paths 참조)에 대해 유사한 "나는 이것을 좋아하지 않습니다" 문제를 제기할 수 있었지만, 나는 무한 필리버스터가 언어 디자인을 수행하는 생산적인 방법이라고 믿지 않습니다.

이 기능이 논의/해결되어야 하는 언어의 다른 부분과 상호 작용하는 방식에 대한 특정 문제가 있는 경우(예: " try { ... } 로 제거할 수 있는 것 같습니다. " 또는 " 관용적으로 큰 기능") 그런 식으로 파일을 제출하는 것이 더 생산적이라고 생각합니다.

@cramertj @Centril 이 명시적으로 제안하지 않았다면 그런 문제를 제기하지 않았을 것입니다. (개인적으로 FCP가 제안되지 않았더라면 더 좋았을 것입니다.)

당신은 누군가가 "가까운"이외의 뭔가를 rfcbot와 P-FCP을 제기 한 경우, "이 폐쇄해야한다"에 해당하는 과정으로 어떤 제안? "적절하게 해결/해결되었는지 확인하십시오"는 "언젠가 안정화될 것입니다. 거기에 도달하려면 무엇이 필요합니까?"와 동일하게 들립니다. "이것은 결코 안정화되어서는 안되며 언어의 일부가되어서는 안됩니다"라는 흐름에 경로를 남기지 않습니다.

프로세스에 대한 나의 이해는 선택되지 않은 확인란을 사용하여 동의하지 않음을 표시하는 것이었습니다.

그런 다음 계속 진행하려면 모든 확인란을 선택하도록 프로세스를 다시 변경해야 합니다.

나는 무한 필리버스터가 언어 디자인을 하는 생산적인 방법이라고 믿지 않습니다.

저도 아니라고 생각합니다. 저도 이 결론을 내릴 수 있는 길을 찾고 싶습니다. 다만 다른 방향으로 결론이 났으면 하는 바람입니다.

기록을 위해 이 RFC에 대한 경험을 바탕으로 "안정화 중에 계속 진행해야 하는지 여부를 평가/처리할 수 있습니다"라는 경고로 RFC에 다시 응답하는 것은 좋은 생각이 아니라고 생각합니다. 그렇게 하면 이와 같은 중요한 절차상의 문제가 발생합니다.

"예, 이 개별 기능이 언어를 더 표현력 있게 만드는 방법을 알 수 있지만 언어의 전반적인 평가를 기반으로 하면 무게를 지탱하지 않으며 더 이상 확장하고 싶지 않습니다. 이런 식으로 언어의 표면적". 제안된 모든 기능이 어떤 형태로든 불가피한 것으로 간주되고 반대를 진압하고 지속하는 문제로 보이지 않도록 정기적으로 전화를 걸어야 한다고 생각합니다.

놓친 것 같아서 이전에 말한 것을 반복하겠습니다. https://github.com/rust-lang/rust/issues/48594#issuecomment -451795597

기본적으로 루프를 사용하는 것과 브레이킹 블록을 사용하는 것의 차이점에 대해 이야기했습니다.

주로, 차단 블록은 다른 구문, (약간) 다른 의미를 가지며(적어도 레이블이 지정되지 않은 중단과 관련하여) 다른 의도를 의미하며 몇 가지 기타 사소한 사항을 의미합니다.

rfcbot은 anticoncerns를 지원합니까?

@joshtriplett

"예, 이 개별 기능이 언어를 더 표현력 있게 만드는 방법을 알 수 있지만 언어의 전반적인 평가를 기반으로 하면 무게를 지탱하지 않으며 더 이상 확장하고 싶지 않습니다. 이런 식으로 언어의 표면적". 제안된 모든 기능이 어떤 형태로든 불가피한 것으로 간주되고 반대를 진압하고 지속하는 문제로 보이지 않도록 정기적으로 전화를 걸어야 한다고 생각합니다.

예, 기능을 수락하거나 거부하려면 해당 팀의 완전한 합의가 필요하다는 것은 현재 프로세스의 불행한 위험입니다. lang 팀이 지금만큼 크면 항상 이것을 달성하기가 어렵습니다. 위의 댓글에서 이 기능이 왜 중요한지 동기를 부여하는 코드 예제가 누락된 것이라고 생각했지만 이제는 거기에 동의하는 것처럼 들립니다. 이 기능을 사용하여 더 잘 작성할 수 있는 코드이지만 여기에서 볼 수 있는 비용의 가치가 있는지 확신하지 못합니다. 계속해서 예제를 제공하는 것(말 그대로 다른 스타일로 작성하는 것이 불가능한 매크로 예제 포함)만으로는 충분하지 않은 것처럼 보이기 때문에 이러한 사례가 충분한 동기 부여라고 확신할 수 있는 방법이 없습니다.

유사하게, 나는 개인적으로 이 기능이 병합되어야 한다고 확신할 것이라고 상당히 확신합니다. IMO는 그것이 최고의/유일한 옵션인 다양한 예를 통해 그 무게를 끌어낼 뿐만 아니라 언어가 실제로 추가되어 더 간단합니다. (라벨이 붙은 블록을 허용 하지 않는 것은 우리가 다른 라벨이 붙은 구성을 허용한다는 점에서 놀랍습니다.)

위의 요약된 귀하의 입장에 동의하신다면, 우리는 프로세스가 부족한 불행한(내 생각에는 역사적으로!) 곤경에 처해 있는 것 같습니다. 한 가지 옵션은 위에서 설명한 것처럼 현재 rfcbot 규칙을 해석하는 것입니다. "확인란이 없으면 동의하지 않는다는 신호가 표시됩니다. 대다수를 무효화하려면 3명의 구성원이 필요합니다." 나는 당신이 이 절차를 따라야 한다고 제안한 것이 정직하지 않다고 생각합니다.

이전에 승인된->구현된->안정화된 기능에 대한 시간 제한을 도입할 수 있고 계속 증가하는 백로그를 피하기 위해 뒤쳐지는 기능을 "자동 종료"해야 한다는 제안을 들었습니다. 그와 같은 것이 이 경우를 해결할 수 있습니다. 저(그리고 제 생각에 팀의 다른 여러 사람)는 체크박스를 닫지 않고 수락할 체크박스를 표시하지 않을 것입니다(나는 지금도 이렇게 말하는 것조차 두렵습니다. m 당신을 설득하기 위해 최후의 노력을 버리고 있습니다! :스마일:).

나는 계속해서 성장하는 팀과 함께 기능에 대한 합의에 도달하는 능력을 잃을 것이고, 특히 lang-design 팀에서 일관된 방식으로 언어를 조정하는 것이 어려울 것이라고 걱정합니다. 팀 크기 제한은 이에 대한 명백한 해결책처럼 보입니다. 많은 사람들의 의견을 받는 것은 가능하지만 충분히 큰 그룹 간에 절대적인 합의를 구축하는 것은 불가능합니다. 다른 사람들은 논쟁의 여지가 있는 기능이 잘못된 기능으로부터 언어를 보호하기 위해 병합되어서는 안 된다고 주장할 것입니다. 저는 개인적으로 커뮤니티가 적절한 경고 없이 많은 실수를 저지르도록 내버려 두지 않을 것이라고 생각하지만, 그것은 생각입니다.

나는 여기에서 프로세스 진화에 대해 논의하기 위해 별도의 스레드를 시작하려고 노력할 것이며, 그 동안 이 스레드에 관심을 갖고 있는 사람들이 다음과 현저하게 다른 고려해야 할 새롭고 중요한 사용 사례가 있는 경우에만 게시할 것을 요청합니다. 또는 이 기능이 언어에 추가되어서는 안 되는 중대한 고려되지 않은 이유가 있는 경우. 이러한 메가 스레드의 전체 기록을 읽는 것은 어렵지만 게시물이 계속해서 반복되거나 스레드가 도움이 되지 않는 댓글로 채워지면 더욱 그렇습니다. (그는 이제 전체 스레드에서 가장 긴 주석 중 하나를 입력했다고 말합니다 XD)

TL;DR: 우리가 갇힌 것 같아요. 이에 대한 프로세스가 있어야 합니다. 그 대화를 다른 곳에서 시작하고 여기에 링크하겠습니다. 그렇지 않으면 고려해야 할 중요한 새 정보가 없는 한 댓글을 달지 마십시오.

@cramertj

기능을 수락하거나 거부하려면 해당 팀의 완전한 합의가 필요하다는 것은 현재 프로세스의 불행한 위험입니다.

나는 솔직히 그것을 기능이라고 생각합니다.

위의 의견에서 이 기능이 왜 중요한지 동기를 부여하기 위한 코드 예제가 누락되었다고 생각했지만 이제 이 기능을 사용하여 더 잘 작성할 수 있는 코드가 있다는 데 동의하지만 가치가 있는지 확신하지 못하는 것 같습니다. 여기에 표시되는 비용.

나는 여전히 많은 예제 가 다른 방식으로 작성 수 있는 예제를 더 많이 볼수록 이 기능이 단순히 언어에 들어가지 않아야 한다는

(또한 가치가 주목할 : @nrc의 상자 proc-macro-rules 사용되는 label_break_value 그것을 방지하기 위해 다시 작성되었습니다 것 같습니다.)

한 가지 옵션은 위에서 설명한 것처럼 현재 rfcbot 규칙을 해석하는 것입니다. "확인란이 없으면 동의하지 않는다는 신호가 표시됩니다. 대다수를 무효화하려면 3명의 구성원이 필요합니다." 나는 당신이 이 절차를 따라야 한다고 제안한 것이 정직하지 않다고 생각합니다.

나는 그것이 "기권"에 대한 올바른 절차라고 생각하지만 반대하는 것은 아닙니다.

IMO는 최고의/유일한 옵션인 다양한 예를 통해 무게를 끌어올릴 뿐만 아니라 추가로 언어가 실제로 더 간단합니다(다른 레이블이 지정된 구성을 허용하는 경우 레이블이 지정된 블록을 허용하지 않는 것이 놀랍기 때문입니다).

나는 일반적으로 직교성 인수가 매력적이라고 ​​생각하지만 개인적으로 언어에 레이블이 지정된 루프 브레이크를 사용하지 않는 것을 선호했기 때문에 특히 이 인수는 설득력이 없습니다.

나는 계속해서 성장하는 팀과 함께 기능에 대한 합의에 도달하는 능력을 잃을 것이고, 특히 lang-design 팀에서 일관된 방식으로 언어를 조정하는 것이 어려울 것이라고 걱정합니다.

조향뿐 아니라 정지도 걱정입니다. 프로세스가 "예"로 가는 경로를 찾는 데 초점을 맞추는 것처럼 보이지만 흐름도에 "아니요", "아직은 아님"으로 이어지는 그래프 가장자리가 없는 경우 가끔 발생하는 특정 불가피성이 있습니다.

2018년과 2019년에 언어의 기능 성장에 대해 많은 게시물이 작성되었으며 언어 팀에서 언어의 전체 표면적에 대해 진지하게 고려해야 한다고 생각합니다. 그리고 그렇게 하도록 장려하는 좋은 프로세스가 없는 것 같습니다.

@joshtriplett

이것은 언어에 표현할 수 없는 표현력을 추가하지 않습니다.

매우 명확하기 : 정확히 이렇게 않습니다. 현재 다른 제어 흐름 구성을 방해하지 않는 이 코드를 표현할 방법이 없습니다. 다른 제어 흐름 구성은 매크로에서 특히 바람직합니다. 이 구성은 레이블이 지정되지 않은 중단을 통해 타겟팅할 수 없는 유일한 구성이 됩니다. 매크로 작성자가 사용자가 제공한 break 와 겹칠 위험 없이 섹션을 분리할 수 있습니다.

또한 지그재그로 둘러싸거나(레이블이 전혀 없는 경우 - Lua 예제 참조) 루프로 이상한 작업을 수행할 필요가 없으므로 코드를 더 읽기 쉽게 만듭니다. 이것은 또한 llvm이 지그재그 코드를 최적화할 수 있어야 하는 경우에도 약간의 성능 이점이 있습니다.

@joshtriplett

나는 여전히 많은 예제가 다른 방식으로 작성될 _수도_ 있다고 생각합니다. 이것은 언어에 표현할 수 없는 표현력을 추가하지 않습니다. 나는 원래 충분한 예제로 동기를 부여할 수 있다고 느꼈지만 이 기능을 _할 수 있는_ 예제가 많을수록 이 기능이 단순히 언어에 포함되어서는

우리가 파헤칠 수 있는 것이 아닐까요?

나는 일반적으로 직교성 인수가 매력적이라고 ​​생각하지만 개인적으로 언어에 레이블이 지정된 루프 브레이크를 사용하지 않는 것을 선호했기 때문에 특히 이 인수는 설득력이 없습니다.

이 추론 라인이 이상하다고 생각합니다(판으로 레이블이 지정된 루프 중단을 제거하지 않으려는 경우 제외). 언어에 없었으면 하는 바를 기반으로 디자인 결정을 내리는 것은 적절하지 않은 것 같습니다. 거기에 있으므로 이 추가가 그것과 일치하는지 여부를 고려해야 합니다. 그렇지 않으면 내가 Rust에 대해 다르게 했을 수 있는 많은 일이 있지만, 해서는 안 되며 해서는 안 됩니다.

조향뿐 아니라 _정지_에 대해서도 걱정합니다. 프로세스가 "예"로 가는 경로를 찾는 데 초점을 맞추는 것처럼 보이지만 흐름도에 "아니요", "아직은 아님"으로 이어지는 그래프 가장자리가 없는 경우 가끔 발생하는 특정 불가피성이 있습니다.

Not yet은 yes 없이는 안정화되지 않는다는 의미에서 "no"의 자체 형태입니다. 게다가, 우리 모두에게 LBV가 나쁜 생각이라는 것을 납득시키십시오 / X, Y, Z 이유로 충분히 동기가 부여되지 않았습니다. 나는 아직까지 그러한 구체적인 주장을 많이 들어본 적이 없다. 당신은 또한 불가피한 것이 없다는 것을 여기에서 분명히 보여주었습니다.

2018년과 2019년에 언어의 기능 성장에 대해 많은 게시물이 작성되었으며 언어 팀에서 언어의 전체 표면적을 _심각하게_ 고려해야 한다고 생각합니다. 그리고 그렇게 하도록 장려하는 좋은 프로세스가 없는 것 같습니다.

나는 개인적으로이 글의 많은 대해 하나 느끼는 지속 가능성 (그러나 @nikomatsakis이 ...했던만큼 적절하게 표현되지 않음) 또는 많은 사람들이 즉, 우리가 이미 전체에 심각한 고려를 할 (언어 팀이 어떻게 작동하는지 이해하지 않는다 표면적). Rust의 전체 표면 구문은 아마도 실제로 작년에 성장한 것이 아니라 줄어들었을 것입니다. LBV는 크게 증가하지 않으며 실제로 언어의 생산 수를 줄이고 구문을 더 균일하게 만든다는 주장이 제기될 수 있습니다.

단순히 문법을 결합하는 것만으로는 언어의 표면적을 축소하지 않습니다 .

취할 수 있는 조건부 분기의 수를 줄이는 것은 틀림없이 언어의 표면적을 축소하는 것입니다.

저는 이 특정 기능이 어느 쪽이든 상관없다고 생각합니다. 아마도 중립적일 것입니다. 그러나 예를 들어 언어 구성을 통합하는 것(bool let, 누구라도?) 은 표면적을 축소합니다.

그만한 가치가 있기 때문에 매크로가 있는 다중 패러다임 언어라는 점에서 Rust와 유사한 Common Lisp에는 이 기능이 있습니다(이름 block / return-from ). 여기에서 논의된 것과 유사하게 Common Lisp에서 이 구성은 매크로를 작성하고 환원할 수 없을 정도로 복잡한 제어 흐름을 표현할 때 종종 유용합니다.

(block foo
  (return-from foo "value"))

내 생각에 Common Lisp에서는 이 기능이 성공적인 것으로 간주됩니다. 언어를 배우거나 구현하기 어렵게 만드는 기능에 대한 대화에서는 나오지 않습니다.

포함이 있다

early return from block ⊂ exceptions ⊂ call/cc

예를 들어, Scheme에서 return-from 의 다음 에뮬레이션이 가능합니다.

(define call/cc call-with-current-continuation)

(define-syntax block
    (syntax-rules ()
        ((_ label statements ...)
            (call/cc (lambda (label) (begin statements ...))))))

(block foo
    (display "Visible text")
    (foo "value")
    (display "Phantom text"))

Scheme에서 call/cc 는 논란의 여지가 있는 성공적인 것으로 간주됩니다. 나는 이것을 특히 흥미롭게 생각합니다. 왜냐하면 그것에 대해 이야기할 수 있으려면 먼저 대상을 공식화해야 하기 때문입니다. call/cc 를 오작동이라고 생각해도 지적인 의미에서 언어를 더 실질적으로 만들었다.

Nemerle 언어에는 명명된 블록 기능이 있습니다.
매우 유용하고 편리합니다.

return, break 및 continue 는 이 기능을 사용하여 매크로로 구현됩니다.

@jhpratt 문제의 토론을 읽어보십시오.

@Centril 의 제안에서 에 대한 몇 가지 의견을 반복합니다.

이 기능에 대해 논의하면서 다음과 같은 영감을 제안했습니다(일반적인 루프 관련 버전과 반대).

어쨌든 루프는 여기에서 제 영감이 아닙니다. 내가 try 블록을 볼 때 "클로저를 만드는 수고를 들이지 않고도 조기 반환으로 짧은 로컬 계산을 작성할 수 있으면 유용할 것"이라고 생각합니다. try 블록은 다소 제한된 "impl Try를 반환하고 싶습니다"에 대해 작동하며 어떤 종류의 레이블도 지원하지 않습니다.

위의 내용은 이에 대한 저의 주요 사용 사례입니다. 저는 조기 복귀 스타일을 좋아합니다. try {} 블록은 대부분의 방법을 제공하지만 레이블을 실제로 지원하지 않습니다(중첩 블록에 대해 try {}? 을 작성하기 때문에 필요하지 않음). 당신은 당신의 유형을 캐치올이 아닌 특정 모나딕 형태로 삽니다(제공된 사용 사례에 의해 입증됨).

나는 또한 레이블 break/continue가 없는 것이 특히 Rust와 같은 반복자가 없는 경우 매우 고통스러운 C++에 대해 몇 가지 관찰을 했습니다. 예를 들어, 내부 루프 외부에 -UB goto 또는 로컬 break 플러스 조건부 continue 없이 내부 루프에서 외부 루프를 계속할 수 있는 방법이 없습니다.

적어도 C에서 + + 빌림 검사기의의 부족은 덜 고통스러운 인라인 람다 트릭 않는, 효과적으로 지원 LVB는, 인라인 람다에 반환 이후 LLVM의 inliner에 의해 LVB 같은으로 전환됩니다한다. 이와 같은 것은... Rust에서 훨씬 더 의심스럽습니다.

나는 또한 이 기능이 Go의 goto 표현력과 거의 동일하다는 점을 지적해야 합니다. 이 기능은 컴파일 타임이 선언 및 기타 사항을 건너뛰지 않도록 강제합니다(솔직히 Rob Pike가 goto 가 허용된다고 생각했다면 C++의 문제를 해결하기 위해 노력한 역사, 나는 그를 어느 정도 신뢰할 것입니다.

또한 선행 기술에 대해 알아보려면 Kotlin 도 return<strong i="24">@label</strong> expr; 형식으로 이 정확한 기능을 제공합니다.

디버거가 break function:label 인식할 수 있기 때문에 c'ish 언어에서 나는 들어오는 goto 없이도 루프에서 안정적인 중단점의 위치로 레이블을 사용합니다.
휴식에 대한 합의가 없더라도 레이블은 좋을 수 있습니다.

편집: 한 가지 잠재적인 장애물은 일반적으로 레이블이 기호 명명 규칙을 따른다는 것입니다. RFC를 이해하면 이러한 레이블은 기호 이름에서 '가 유효하지 않은 기호 명명 규칙을 따르지 않습니다.
예를 들어 Dwarf 또는 gdb 자체에서 실제로 어떤 문제가 있는 경우에는 확실하지 않습니다.

편집2:
일반적인 C 기반 레이블의 인용 동작을 살펴보면 약간의 연기가 있음이 확실합니다.
디버거에서 gdb는 기호 이름의 일부가 아닌 인용을 위해 최소한 따옴표를 처리할 것입니다. 다음 결과에서

0x401114의 중단점 1: 파일, 1행.
타의 추종을 불허하는 견적

echo "void main() { } void hmm() { umm: return; }" | gcc -g -x c -;
gdb -ex "b hmm:'umm'" -ex "b hmm:'umm" -batch ./a.out

그리고 이 인용이 기호 일치 전에 발생한다고 믿기 때문에 이것이 gdb의 Rust 언어 특정 지원에 의해 영향을 받을 수 있다고 생각하지 않습니다.

편집: 우주선은 기존 루프 레이블로 인해 아마도 이것으로 항해했을 것입니다.

블록에서 조기 복귀를 선호하는 사소한 점은 가난한 사람의 계약 프로그래밍입니다. 하나는 사전 및 사후 조건으로 assert 문을 추가하기만 하면 됩니다. 편안함을 유지하기 위해 return 를 break 'ret 로 대체하여 이 구성을 허용하는 것이 가능해야 합니다.

let value = 'ret: {
    // ...
};
assert!(postcondition(value));
return value;

그러나 return 는 블록 내부에서 금지되어야 하기 때문에 이것은 불완전한 솔루션입니다.

이 기능을 원했지만 존재하는지 몰랐기 때문에 사용하지 않았다는 메모를 추가하는 것은 "사람들이 얼마나 소수의 사람들이 그것을 사용하는지에 의해 입증된 바와 같이 그것을 원하지 않는다"에 대한 부정적인 수식어라고 생각합니다.

나는 오늘 아침에 IRLO에서 개념을 독립적으로

저는 오늘 이것으로 놀았고 async 블록에서 _매우_ 편리합니다. 그러나 try_blocks 기능과 결합하면 문제가 발생하는 것 같습니다.

#![feature(try_blocks, label_break_value)]

fn main() {
    let _: Result<(), ()> = try {
        'foo: {
            Err(())?;
            break 'foo;
        }
    };
}

error[E0695]: unlabeled `break` inside of a labeled block
 --> src/main.rs:6:20
  |
6 |             Err(())?;
  |                    ^ `break` statements that would diverge to or through a labeled block need to bear a label

error: aborting due to previous error

try 블록은 실수입니다.

... ? 자체에 레이블을 지정할 수 없습니까? ( Err(()) 'foo?; )

나는 try 블록이 실수라는 것에 강력하게 동의하지 않습니다. 비록 그것은 별도의 논의이며 여기에서 앞뒤로 갈 가치가 없을 것입니다.

이 특정 예제에서는 실행 가능하지만 'foo 에 상당한 양의 코드 덩어리와 여러 개의 ? 가 포함되어 있는 실제 코드와 비교하면 매우 최소화됩니다.

@SoniEx2

try 블록은 실수입니다.

이 댓글은 부적절합니다. @jonhoo 의 의견은 (아마도) 버그가 있는 상호 작용을 보고했습니다. try 블록(또는 label-break-value)에 대한 의견에 관계없이 원활하게 상호 운용되어야 한다는 것은 분명합니다.

Err(()) 'foo?; 구문을 사용해야 합니다.

@jonhoo try 가 어떻게 디슈가링 되는지와 관련하여 impl 세부 정보가 누출되는 것을 보고 있는 것 같습니다. 이를 별도의 문제로 제출하고 가능한 수정 사항에 대한 토론을 거기로 옮길 수 있습니까?

RFC는 다음과 같이 말합니다.

'BLOCK_LABEL: { EXPR }

에 대한 구문 설탕입니다.

'BLOCK_LABEL: loop { break { EXPR } }

나는 그 대체를 시도했고 코드는 연결할 수 없는 코드에 대한 경고와 함께 컴파일됩니다.

#![feature(try_blocks, label_break_value)]

fn main() {
    let _: Result<(), ()> = try {
        'foo: loop {
            break {
                Err(())?;
                break 'foo;
            }
        }
    };
}

@nikomatsakis @ciphergoth 는 https://github.com/rust-lang/rust/issues/72483으로 제출되었습니다

나는 더 이상 이것에 반대하지 않는다는 것을 알게 되었습니다. 레이블이 붙은 break의 초기 개념이 오늘날 고려 대상이었다면 더 강력하게 반대했을 것입니다. 그러나 그 개념이 존재한다는 점을 감안할 때 임의의 블록에 대한 적용에 계속 반대하는 것이 합리적이지 않다고 생각합니다.

(이것은 break 사용하는 현재 형식에 적용되며 다른 구문에는 적용되지 않습니다.)

@rfcbot 은 병합하지 않아야
@rfcbot이 검토했습니다.

@joshtriplett "조기 반환"을 수행할 수 있는 유일한 방법이기 때문에 이 방법이 async 블록에서 매우 유용하다는 것을 알았습니다. 다음을 작성하는 대신 다음을 의미합니다.

async {
  // do thing a
  if thing_a_failed {
    // handle specially (note, _not_ ?)
  } else {
    // do thing b
    if thing_b_failed {
      // handle specially (note, _not_ ?)
    } else {
      // do thing c, etc..
    }
  }
}

난 쓸수있다:

async {
  'block {
  // do thing a
  if thing_a_failed {
    // handle specially (note, _not_ ?)
    break 'block;
  }

  // do thing b
  if thing_b_failed {
    // handle specially (note, _not_ ?)
    break 'block;
  }

  // do thing c, etc..
  }
}

이에 깔끔하게 유사 어떻게 할 수있는 조기 복귀 return 함수 /과와 폐쇄 continue/break 루프있다. 분명히 추가 블록이 필요하지 않으면 좋겠지만( async 'block { 가능성?) 중첩된 if-s를 확실히 능가합니다.

비동기 블록이 레이블로 직접 주석 처리되도록 허용하는 것은 이 기능에 대한 아주 좋은 확장처럼 들립니다.

@rfcbot fcp 취소

FCP는 영원히 차단되었으므로 여기서 취소하겠습니다. 우리는 아마도 이 미래를 계속 추진할 것인지 논의해야 할 것입니다. 다른 것이 없다면 비동기 블록을 고려하도록 업데이트되어야 하는 것처럼 보이며, 이 기능에 대한 새로운 사용 사례를 추가하는 것처럼 들립니다.

@nikomatsakis 제안이 취소되었습니다.

비동기 블록이 있는 경우 이 제안의 의미에 대해 모호함이 없다는 점에 유의하십시오. RFC의 정의는 여전히 적용됩니다. 즉,

'BLOCK_LABEL: { EXPR }

단순히 구문 설탕입니다

'BLOCK_LABEL: loop { break { EXPR } }

암시적 루프에 바인딩되는 레이블이 지정되지 않은 중단 또는 계속이 EXPR 내에서 금지된다는 점을 제외하고.

break 레이블 대신 비동기 블록에서 (초기) return 할 수 있으므로 비동기 블록에 레이블을 지정하는 것은 의미가 없습니다.

let fut = async {
    return 42;
    0
};

println!("{}", fut.await); // prints 42

( 놀이터 )

@WaffleLapkin 저는 사실 최근에 제 자신 async _specifically_에 대한 적용 가능성은 나는 처음에 생각했다.