후자!

여기에 대한 WIP 구현이 있습니다. https://github.com/canndrew/rust/tree/bang_type_coerced

현재 상태는 old-trans로 빌드되고 사용 가능하지만 몇 가지 테스트에 실패했습니다. 일부 테스트는 if (return) {} 와 같은 코드가 트랜잭션 중에 충돌을 일으키는 버그로 인해 실패합니다. 다른 테스트는 링크 시간 최적화와 관련이 있으며 항상 버그가 있어서 변경 사항과 관련이 있는지 모르겠습니다.

현재 로드맵은 다음과 같습니다.

• MIR과 함께 작동시키십시오. 이것이 내가 구현을 시작한 방법이므로 너무 어렵지는 않지만 컴파일하는 동안 MIR이 segfault를 빌드하는 문제가 있었습니다.
• 컴파일러( FnOutput , FnDiverging 및 관련 항목)에서 사용되지 않는 분기 항목을 제거합니다.
• 기능 게이트 뒤에 새 유형을 숨깁니다. 이는 기능이 비활성화된 경우 다음을 의미합니다.
  
  
  
  • ! 는 반환 위치에서 유형으로만 구문 분석될 수 있습니다.
  
  
  • 분기형 변수의 기본값은 () 입니다.
  
  
• 기본 () 가 트레잇을 해결하는 데 사용되었을 때 호환성 경고를 발생시키는 방법을 알아보세요. 이를 수행하는 한 가지 방법은 DefaultedUnit 라는 새 유형을 AST에 추가하는 것입니다. 이 유형은 () 처럼 작동하며 어떤 상황에서는 () 로 바뀌지만 특성을 해결할 때 경고를 발생시킵니다( () ). 이 접근 방식의 문제는 구현 시 모든 버그를 포착하고 수정하는 것이 어려울 것이라고 생각합니다. 코드가 깨지는 것을 방지하기 위해 사람들의 코드를 깨뜨리게 될 것입니다.

이 목록에 추가해야 할 사항이 있습니까? 저만 이 일을 하고 있는 건가요? 그리고 이 브랜치를 메인 리포지토리로 옮겨야 합니까?

기본 () 가 트레잇을 해결하는 데 사용될 때 호환성 경고를 발생시키는 방법을 알아보세요. 이를 수행하는 한 가지 방법은 DefaultedUnit 라는 새 유형을 AST에 추가하는 것입니다. 이 유형은 () 처럼 작동하고 어떤 상황에서는 () 로 바뀌지만 특성을 해결할 때 경고를 발생시킵니다( () ). 이 접근 방식의 문제는 구현 시 모든 버그를 포착하고 수정하는 것이 어려울 것이라고 생각합니다. 코드가 깨지는 것을 방지하기 위해 사람들의 코드를 깨뜨리게 될 것입니다.

@eddyb , @arielb1 , @anyone_else : 이 접근 방식에 대한 생각은? 나는 거의 이 단계에 이르렀다(내가 (매우 천천히) 고치려고 하는 몇 가지 실패한 테스트를 제외하고).

어떤 특성을 구현해야 !? 초기 PR #35162에는 Ord 및 기타 몇 가지가 포함됩니다.

! 는 _all_ 특성을 자동으로 구현하지 않아야 합니까?

이런 종류의 코드는 매우 일반적입니다.

trait Baz { ... }

trait Foo {
    type Bar: Baz;

    fn do_something(&self) -> Self::Bar;
}

Bar 가 실제로 존재할 수 없음을 나타내기 위해 ! 를 Foo::Bar 에 사용할 수 있을 것으로 예상합니다.

impl Foo for MyStruct {
    type Bar = !;
    fn do_something(&self) -> ! { panic!() }
}

그러나 이것은 ! 가 모든 특성을 구현하는 경우에만 가능합니다.

@tomaka 그것에 대한 RFC가 있습니다: https://github.com/rust-lang/rfcs/pull/1637

문제는 ! 가 Trait 를 구현하는 경우 !Trait 도 구현해야 한다는 것입니다.

문제는 만약 ! Trait을 구현합니다. !Trait도 구현해야 합니다.

그런 다음 특성 요구 사항을 무시하도록 특수 케이스 ! ?

@tomaka ! 은 특성이 정적 메서드 및 관련 유형/상수를 가질 수 있기 때문에 _all_ 특성을 자동으로 구현할 수 없습니다. 비정적 메서드(예: Self 을 사용하는 메서드)만 있는 특성을 자동으로 구현할 수 있습니다.

!Trait 관해서는 누군가 ! 가 Trait _and_ !Trait 모두를 자동으로 구현할 수 있다고 제안했습니다. 그것이 건전한 것인지 확실하지 않지만 부정적인 특성은 전혀 건전하지 않다고 생각합니다.

하지만 예, ! 가 정확히 이러한 종류의 경우에 대해 제공한 예제에서 Baz 를 자동으로 구현할 수 있다면 좋을 것입니다.

분기 유형 변수를 () / ! 기본 설정하는 것은 정확히 언제이며 충분한 유형 정보를 유추할 수 없다는 오류가 발생하는 경우는 언제입니까? 이것은 어디에나 지정되어 있습니까? 다음 코드를 컴파일할 수 있기를 바랍니다.

let Ok(x) = Ok("hello");

그러나 내가 얻는 첫 번째 오류는 " unable to infer enough type information about _ "입니다. 이 경우 _ 가 ! 로 기본 설정되는 것이 합리적이라고 생각합니다. 그러나 기본 동작에 대한 테스트를 작성할 때 유형 변수를 기본값으로 만드는 것이 놀라울 정도로 어렵다는 것을 알았습니다. 그렇기 때문에 이러한 테스트 는 매우 복잡합니다.

왜 우리가 이 기본 동작을 하는지, 언제 호출해야 하는지에 대한 명확한 정보를 알고 싶습니다.

그러나 내가 받는 첫 번째 오류는 "_에 대한 충분한 유형 정보를 유추할 수 없습니다"입니다. 이 경우 _가 기본적으로 !로 설정되는 것이 합리적이라고 생각합니다. 그러나 기본 동작에 대한 테스트를 작성할 때 유형 변수를 기본값으로 만드는 것이 놀라울 정도로 어렵다는 것을 알았습니다. 그렇기 때문에 이러한 테스트는 매우 복잡합니다.

제 생각에는 아주 좋은 생각입니다. 예를 들어 기본적으로 Option<!> None 와 동일합니다.

@carllerche

unit_fallback 테스트는 확실히 그것을 증명하는 이상한 방법입니다. 덜 거시적인 버전은

trait Balls: Default {}
impl Balls for () {}

struct Flah;

impl Flah {
    fn flah<T: Balls>(&self) -> T {
        Default::default()
    }
}

fn doit(cond: bool) {
    let _ = if cond {
        Flah.flah()
    } else {
        return
    };
}

fn main() {
    let _ = doit(true);
}

return / break / panic!() 의해 생성된 유형 변수만 기본값으로 설정됩니다.

정확히 언제 우리는 ()/! 충분한 유형 정보를 유추할 수 없다는 오류가 발생하는 경우는 언제입니까? 이것은 어디에나 지정되어 있습니까?

"지정"을 정의합니다. :) 대답은 코드 외부에 기록되지 않은 특정 작업을 수행하려면 해당 시점에서 유형을 알아야 한다는 것입니다. 가장 일반적인 경우는 필드 액세스( .f ) 및 메서드 디스패치( .f() )이지만 다른 예는 deref( *x )이며 아마도 하나 또는 두 개 더 있을 것입니다. 이것이 요구되는 데에는 대부분 합당한 이유가 있습니다. 일반적으로 말하자면, 진행해야 할 여러 가지 방법이 있으며 어떤 방법을 택할지 모르면 진행할 수 없습니다. (잠재적으로 코드를 리팩토링하여 이러한 요구가 일종의 "보류 의무"로 등록될 수 있지만 그렇게 하는 것은 복잡합니다.)

fn의 끝까지 만들면 정상 상태에 도달할 때까지 보류 중인 모든 특성 선택 작업을 실행합니다. 이것은 기본값(예: i32 등)이 적용되는 지점입니다. 이 마지막 부분은 RFC에서 사용자 지정 기본 유형 매개변수에 대해 설명합니다(RFC는 일반적으로 작동해야 함).

https://github.com/rust-lang/rust/issues/36011
https://github.com/rust-lang/rust/issues/36038
https://github.com/rust-lang/rust/issues/35940

보류 중인 문제 목록에 추가할 몇 가지 버그가 있습니다.

@canndrew 는 https://github.com/rust-lang/rust/issues/12609 와 약간 비슷합니다.

이봐, 그건 오래된 버그야! 하지만 예, 내 #36038은 그 속임수라고 말하고 싶습니다(이전에 어디선가 본 적이 있다고 생각했습니다). ! 는 문제가 해결될 때까지 황금 시간대에 고려될 수 없다고 생각합니다.

! 이 패턴 일치 완전성에 영향을 줄 계획입니까? 현재의 잘못된 동작의 예:

#![feature(never_type)]

fn main() {
    let result: Result<_, !> = Ok(1);
    match result {
//        ^^^^^^ pattern `Err(_)` not covered
        Ok(i) => println!("{}", i),
    }
}

@tikue 네, 위에 나열된 버그 중 하나입니다.

@lfairy 웁스 , 상단 체크박스에 나열되지 않아서 못

From<!> for T 및 Add<T> for ! ( ! 의 출력 유형 사용)을 구현할 계획이 있습니까? 정말 이상하게 구체적인 요청이라는 것을 압니다. 이 PR 에서 둘 다 사용하려고 합니다.

From<!> for T 확실히. Add<T> for ! 는 아마도 libs 팀이 결정할 일이지만 개인적으로 ! 는 논리적이고 표준적인 구현이 있는 모든 특성을 구현해야 한다고 생각합니다.

@canndrew 감사합니다! 나는 모든 유형의 하위 유형인 스칼라의 Nothing 특성에 익숙하므로 값이 나타날 수 있는 거의 모든 곳에서 사용할 수 있습니다. 그러나 impl All for ! 또는 이와 유사한 것이 특히 부정적인 특성 경계와 관련하여 Rust의 유형 시스템에 미치는 영향을 이해하려는 열망에는 확실히 공감합니다.

https://github.com/rust-lang/rfcs/issues/1723#issuecomment -241595070 From<!> for T 에 일관성 문제가 있습니다.

아 맞다. 이에 대해 조치를 취해야 합니다.

특성 impls가 다른 특성 impls에 의해 재정의됨을 명시적으로 명시할 수 있다면 좋을 것입니다. 다음과 같은 것:

impl<T> From<T> for T
    overridden_by<T> From<!> for T
{ ... }

impl<T> From<!> for T { ... }

이거 전문화 안되나요? 편집 : 이것이 격자 impl 규칙이라고 생각합니다.

무인도에 대한 특별지원을 최대한 피하는 것이 가능한 대안인가?

이 모든 match (res: Res<A, !>) { Ok(a) /* No Err */ } , Result 대한 특수 메서드 는 기능을 위한 기능처럼 매우 고안된 것처럼 보이며 노력과 복잡성에 대한 가치가 없는 것 같습니다.
! 가 @canndrew 의 애완용 기능이라는 것을 이해하고 그는 더 개발하기를 원하지만 처음부터 잘못된 방향으로 가고 #12609는 버그도 아닙니다.

@petrochenkov #12609는 Never 유형의 특수 기능이 아닙니다. 분명히 도달할 수 없는 일부 코드를 감지하기 위한 버그 수정입니다.

@petrochenkov ! 잊어버리고 열거형만 보세요.

두 가지 변형이 있는 열거형이 있는 경우 두 가지 경우와 일치시킬 수 있습니다.

enum Foo {
    Flim,
    Flam,
}

let foo: Foo = ...;
match foo {
    Foo::Flim => ...,
    Foo::Flam => ...,
}

이것은 2개가 아닌 모든 n에 대해 작동합니다. 따라서 변형이 없는 열거형이 있는 경우 케이스가 없는 열거형과 일치시킬 수 있습니다.

enum Void {
}

let void: Void = ...;
match void {
}

여태까지는 그런대로 잘됐다. 하지만 중첩된 패턴에 대해 일치시키려고 하면 어떤 일이 발생하는지 보십시오. 다음은 Result 내부의 두 가지 변형 열거형에 대한 일치입니다.

enum Foo {
    Flim,
    Flam,
}

let result_foo: Result<T, Foo> = ...;
match result_foo {
    Ok(t) => ...,
    Err(Flim) => ...,
    Err(Flam) => ...,
}

외부 패턴 내부에 내부 패턴을 확장할 수 있습니다. 두 개의 Foo 변형이 있으므로 Err 대한 두 가지 경우가 있습니다. Result 및 Foo 에서 일치시키기 위해 별도의 일치 문이 필요하지 않습니다. 이것은 여러 변형이 있는 열거형에 대해 작동합니다... _0 제외_.

enum Void {
}

let result_void: Result<T, Void> = ...;
match result_void {
    Ok(t) => ...,
    // ERROR!
}

왜 이것이 작동하지 않아야 합니까? 나는 이것을 수정이라고 부르지 않고 무인 유형에 대한 "특별 지원"을 추가하는 것을 불일치 수정이라고 부릅니다.

@petrochenkov 아마도 당신이 말한 것을 오해했을 것입니다. #12609 스레드에서 논의된 두 가지 질문이 있습니다.

(0) 이 코드를 컴파일할 수 있어야 합니까?

let res: Result<u32, !> = ...;
match res {
    Ok(x) => ...,
}

(1) 이 코드를 컴파일할 수 있어야 합니까?

let res: Result<u32, !> = ...;
match res {
    Ok(x) => ...,
    Err(_) => ...,
}

현재 구현된 대로 대답은 각각 "아니오"와 "예"입니다. #12609는 문제 자체에서 구체적으로 (1)에 대해 이야기하지만 답변할 때 (0)을 생각하고 있었습니다. 답이 _해야 하는_ 것에 관해서는 (0)은 확실히 "예"여야 한다고 생각하지만 (1)에 대해서는 저도 잘 모르겠습니다.

@canndrew
(1), 즉, 도달할 수 없는 패턴을 보푸라기(lint)로 만드는 것이 합리적일 수 있으며, 거주하지 않는 유형에 관계없이 하드 오류가 아닙니다. RFC 1445 에는 이것이 왜 유용할 수 있는지에 대한 더 많은 예가 포함되어 있습니다.

(0)에 관해서 나는 당신의 설명에 다소 확신이 있습니다. 이 체계가 컴파일러의 패턴 검사 구현에 자연스럽게 놓여 있고 추가하는 것보다 더 많은 특수 코드를 제거한다면 나는 완전히 기쁠 것입니다.

그건 그렇고, 나는 여기에서 (0)을 수정하기 위해 PR을 했습니다: https://github.com/rust-lang/rust/pull/36476

이 체계가 컴파일러의 패턴 검사 구현에 자연스럽게 놓여 있고 추가하는 것보다 더 많은 특수 코드를 제거한다면 나는 완전히 기쁠 것입니다.

이상하게도 그렇지 않습니다. 그러나 그것은 아마도 우아한 방법이 없기보다는 기존 코드에 해킹한 방식의 인공물일 것입니다.

매크로의 경우 (1)이 어려운 오류가 아닌 것이 유용하다고 생각합니다.

(1) 기본적으로 컴파일되어야 하지만 다음과 같은 린트에서 경고를 제공해야 한다고 생각합니다.

fn a() -> u32 {
    return 4;
    5
}

warning: unreachable expression, #[warn(unreachable_code)] on by default

우리가 그것에 있는 동안 ! 직면하여 일부 패턴을 반박할 수 없도록 만드는 것이 의미가 있습니까?

let res: Result<u32, !> = ...;
let Ok(value) = res;

나는 완전하지 않은 일치를 오류로 만드는 데 동의하지만 도달할 수 없는 즉, 중복 패턴은 경고일 뿐인 것 같습니다.

나는 썩은 것을 모으는 동안 잠시 동안 앉아있는 몇몇 PR을 가지고 있었다. 이러한 검토를 돕기 위해 내가 할 수 있는 일이 있습니까? 아마도 그들에 대한 논의가 필요할 것입니다. #36476, #36449, #36489에 대해 이야기하고 있습니다.

나는 발산 유형(또는 유형 이론의 "하위" 유형)이 비어 있는 enum 유형(또는 유형 이론의 "0" 유형)과 동일하다고 생각하는 아이디어에 반대합니다. 둘 다 가치나 사례를 가질 수는 없지만 서로 다른 생물입니다.

내 생각에 맨 아래 유형은 반환 유형을 나타내는 모든 컨텍스트에서만 나타날 수 있습니다. 예를 들어,

fn(A,B)->!
fn(A,fn(B,C)->!)->!

하지만 말해서는 안 된다.

let g:! = panic!("whatever");

또는

fn(x:!) -> !{
     x
}

또는

type ID=fn(!)->!;

변수에는 ! 유형이 없어야 하므로 입력 변수에는 ! 유형이 없어야 합니다.

이 경우 비어 있는 enum 는 다릅니다. 다음과 같이 말할 수 있습니다.

enum Empty {}

impl Empty {
    fn new() -> Empty {
         panic!("empty");
    }
}

그 다음에

 match Empty::new() {}

즉, ! 와 Empty 사이에는 근본적인 차이가 있습니다. ! 유형의 변수를 선언할 수는 없지만 Empty 대해서는 그렇게 할 수 있습니다. .

@earthengine 두 종류의 거주할 수 없는 유형 사이에 이러한 구분을 도입하는 것(내 눈에는 완전히 인공적인)의 이점은 무엇입니까?

이러한 구분이 없는 많은 이유가 제기되었습니다. 예를 들어 Result<!, E> 를 작성할 수 있고, 이것이 분기 함수와 원활하게 상호 작용하면서 Result 에 대한 모나딕 연산을 계속 사용할 수 있습니다 map 및 map_err .

함수형 프로그래밍에서 빈 유형( zero )은 함수가 반환하지 않거나 값이 존재하지 않는다는 사실을 인코딩하는 데 자주 사용됩니다. bottom 유형이라고 하면 유형 이론의 어떤 개념을 말하는지 명확하지 않습니다. 일반적으로 bottom 는 모든 유형의 하위 유형인 유형의 이름입니다. 그러나 그런 의미에서 ! 아닌 bottom 가 아닙니다. 그러나 다시 zero 가 bottom 유형이 아닌 것은 유형 이론에서 드문 일이 아닙니다.

즉, ! 와 Empty 사이에는 근본적인 차이가 있습니다. ! 유형의 변수를 선언할 수 없지만 Empty 대해서는 그렇게 할 수 있습니다. .

이것이 이 RFC가 수정하고 있는 것입니다. ! 는 유형처럼 사용할 수 없다면 실제로 "유형"이 아닙니다.

@RalfJung
이러한 개념은 선형 논리 https://en.wikipedia.org/wiki/Linear_logic 에서 가져온 것입니다.

이 글의 이전 글에 오타가 있어 삭제했습니다. 내가 그것을 얻으면 이것을 업데이트 할 것입니다.

top 는 가능한 모든 방법으로 사용할 수 있는 값입니다.

서브타이핑에서 이것은 무엇을 의미합니까? 그것은 어떤 유형이 될 수 있습니까? 왜냐하면 그것은 bottom 이기 때문입니다.

@eddyb 제가 실수를 했습니다. 새로운 업데이트를 기다려주세요.

하루 만에 병합된 이 PR 은 한 달 넘게 검토 중인 내 패턴 일치 PR 과 매우 심하게 충돌합니다. 죄송합니다 . 첫 번째 패턴 일치 PR 이후로

ffs 녀석들

@canndrew argh , 죄송합니다. =(오늘도 당신의 PR을 r+할 계획이었는데...

죄송합니다. 징징거리고 싶지는 않지만 이 일이 계속되고 있습니다. 한 번에 여러 PR을 유지하는 것을 포기했고 지금은 9월부터 이 한 가지 변경 사항을 적용하려고 노력하고 있습니다. 문제의 일부는 시간대의 차이라고 생각합니다. 제가 침대에 누워 있는 동안에는 모두 온라인 상태이므로 이 문제에 대해 이야기하기가 어렵습니다.

예외가 유형 시스템에서 논리적이고 필요한 구멍이라는 점을 감안할 때 !를 사용하여 더 공식적으로 예외를 처리하는 방향으로 진지하게 생각한 사람이 있는지 궁금합니다.

https://is.gd/4EC1Dk 를 예제이자 참조점으로 사용하고, 그것을 지나치면 어떻게 될까요?

1) 패닉을 일으킬 수 있지만 오류를 반환하지 않는 함수를 처리하거나 결과에 유형 서명이 암시적으로 -> Foo 에서 -> Result<Foo,!> 2) any 결과types would have their Error types implicitly be converted to enum AnonMyErrWrapper { Die(!),Error}```
3) 이후! 거주할 수 없는 크기가 0인 광고입니다. 유형 간에 변환하는 데 드는 비용이 없으며, 이전 버전과 호환되도록 암시적 변환이 추가될 수 있습니다.

물론 이점은 예외가 유형 시스템으로 효과적으로 들어 올려지고 이에 대해 추론하고 정적 분석을 수행하는 등이 가능하다는 것입니다.

나는 이것이 기술적인 관점이 아니라면 커뮤니티 관점에서 ...사소하지 않을 것이라는 것을 알고 있습니다. :)

또한 이것은 아마도 미래의 가능한 효과 시스템과 겹칠 것입니다.

@tupshin 최소한 많은 체조 없이는 획기적인 변화입니다. 명확성을 원한다면 해제를 비활성화하고 "결과"를 수동으로 사용하는 것이 좋습니다. [그리고 btw, 이 문제는 실제로 그런 것을 제기할 장소가 아닙니다. ! 의 디자인은 당신이 문제를 제기하는 것이 아니므로 이것은 순전히 미래의 작업입니다.]

나는 적어도 중요한 체조와 그것이 완전히 미래의 작업이라는 공정한 지적 없이는 그것을 깨뜨릴 수 있다는 것을 알고 있습니다. 그리고 예, 나는 계획된 것에 매우 만족합니다! 어디까지나. :)

@nikomatsakis 보류 중인 문제와 관련하여 이 두 가지를 확인할 수 있습니다.

• #35162의 코드 정리, expr_ty를 호출하는 대신 반환 위치를 통해 typeck를 스레드 유형으로 재구성합니다.
• 성냥에서 사람이 살지 않는 유형의 처리 해결

나는 이것에서 또 다른 균열을 시작할 것입니다.

• ()에 의존하는 사람들에 대한 경고를 구현하는 방법: 해당 동작이 미래에 변경될 수 있는 특성 폴백?

TyTuple 에 플래그를 추가하여 분기 유형 변수를 기본값으로 설정한 다음 특성 선택에서 해당 플래그를 확인하여 생성되었음을 나타낼 계획입니다.

@canndrew

저는 TyTuple에 플래그를 추가하여 분기 유형 변수를 기본값으로 설정한 다음 특성 선택에서 해당 플래그를 확인하여 생성되었음을 나타낼 계획입니다.

큰 확인!

글쎄, 어쩌면 좋아. =) 의미상 동일한 두 가지 유형( () vs () )을 갖는 것은 약간 복잡하게 들리지만, 더 좋은 방법은 생각나지 않습니다. =( 그리고 지역 덕분에 어쨌든 많은 코드가 이에 대비해야 합니다.

내 말은 TyTuple bool을 추가한다는 것입니다.

TyTuple(&'tcx Slice<Ty<'tcx>>, bool),

이는 우리가 이 (단위) 튜플에서 특정 특성을 선택하려고 할 때 경고를 발생시켜야 함을 나타냅니다. 이것은 다른 TyDefaultedUnit 를 추가하는 원래 접근 방식보다 안전합니다.

한 번의 경고 주기 동안만 해당 부울을 유지하면 됩니다.

uninitialized / transmute / MaybeUninitialized 문제와 관련하여 현명한 조치는 다음과 같습니다.

• 추가 MaybeUninitialized 에서, 표준 라이브러리에 mem
• uninitialized 해당 유형에 사람이 거주하는 것으로 알려진 수표를 추가하십시오. 그렇지 않으면 이것이 미래에 어려운 오류가 될 것이라는 메모와 함께 경고를 올립니다. 대신 MaybeUninitialized 사용하는 것이 좋습니다.
• transmute 에 "to" 유형이 "from" 유형인 경우에만 사람이 거주하지 않는다는 확인을 추가합니다. 마찬가지로 하드 오류가 될 경고를 발생시킵니다.

생각?

완전성에 대한 최근 변경 사항에 대해서는 이 스레드를 참조하십시오.

• https://internals.rust-lang.org/t/recent-change-to-make-exhaustiveness-and-uninhabited-types-play-nicer-together/4602

&! 의 의미에 대해 약간의 불일치가 있는 것으로 보입니다. #39151 이후 never_type 기능 게이트가 활성화된 상태에서 매치에서 무인 상태로 처리됩니다.

! 대한 자동 특성 impls가 없으면 적어도 std 에서 적절한 특성을 구현하는 것이 매우 도움이 될 것입니다. 하나 개의 거대한 제한 void::Void 그것이 외부의 살고 있다는 것입니다 std 수단 담요 있고 impl<T> From<Void> for T 그 한계 오류 처리 불가능하다.

나는 적어도 생각 From<!> 모든 종류의 구현해야하며, Error , Display 및 Debug 구현되어야한다 ! .

모든 유형에 대해 최소한 From<!> 가 구현되어야 한다고 생각합니다.

이것은 불행히도 From<T> for T impl과 충돌합니다.

이것은 불행히도 From<T> for T impl과 충돌합니다.

적어도 격자 impl 전문화가 구현될 때까지는.

좋은 점. 언젠가는 완성되기를 바랍니다.

[T; 0] 는 [!; 0] &[T] 하위 유형을 지정하고 &[!] 하위 유형을 지정해야 합니까? 대답은 "예"여야 한다는 것이 직관적으로 보이지만 현재 구현에서는 그렇지 않다고 생각합니다.

[!; 0] 에 사람이 살고 있고 &[!] 사람이 살고 있으므로 아니오라고 말하고 싶습니다. 게다가 이번에는 서브타이핑을 사용하지 않습니다.

[!; 0] 및 &[!] 둘 다 사람이 살지 않아야 하며 두 유형 모두 [] (또는 &[] )을 사용할 수 있습니다.

아무도 그들이 거주하지 않거나 거주하지 않아야한다고 말하지 않았습니다.

let _: u32 = unsafe { mem::transmute(return) };
원칙적으로 이것은 괜찮을 수 있지만 컴파일러는 "0비트와 32비트 사이의 변환"에 대해 불평합니다.

그러나 ! -> () 것은 허용됩니다. 나는 이것을 지적할 특별한 이유가 없습니다. 그것은 모순이지만, 나는 그것에 대한 실용적이거나 이론적 인 문제를 생각할 수 없습니다.

나는 서브타이핑을 기대하지 않을 것이고 컴파일러에서 모든 방식의 로직을 복잡하게 만드는 것을 피한다는 이유로 그것에 반대할 것입니다. 기본적으로 지역이나 지역 결합과 관련이 없는 서브타이핑은 원하지 않습니다.

그것을 구현하는 것이 가능 Fn , FnMut 및 FnOnce 에 대해 ! 가 모든 입력 및 출력 유형을 통해 제네릭하는 방법?

제 경우에는 빌드할 때 호출되는 함수를 사용할 수 있는 일반 빌더가 있습니다.

struct Builder<F: FnOnce(Input) -> Output> {
    func: Option<F>,
}

func 는 Option 이므로 None 사용하는 생성자는 F 유형을 유추할 수 없습니다. 따라서 fn new 구현은 Bang을 사용해야 합니다.

impl Builder<!> {
    pub fn new() -> Builder<!> {
        Builder {
            func: None,
        }
    }
}

빌더의 func 함수는 Builder<!> 및 Builder<F> 모두에서 호출될 다음과 같아야 합니다.

impl<F: FnOnce(Input) -> Output> Builder<F> {
    pub fn func<F2: FnOnce(Input) -> Output>(self, func: F) -> Builder<F2> {
        Builder {
            func: func,
        }
    }
}

이제 문제: 현재 Fn* 특성은 ! 대해 구현되지 않습니다. 또한, 특성에 대한 일반 관련 유형을 가질 수 없습니다(예: Output in Fn ). 그래서 ! 에 대한 Fn* 특성 패밀리를 그럼에도 불구하고 모든 입력 및 출력 유형에 대해 일반적이도록 구현할 수 있습니까?

모순되게 들립니다. <! as Fn>::Output 는 단일 유형으로 해석되어야 하지 않습니까?

<! as Fn>::Output 은 ! , 그렇지 않습니까?

이론상 <! as Fn>::Output 은 ! <! as Fn>::Output 이어야 하지만 현재 유형 검사기는 연결된 유형이 정확히 일치하기를 원합니다: https://is.gd/4Mkxfm

@SimonSapin 단일 유형으로 해결해야 하므로 내 질문을 제기합니다. 언어의 관점에서 그것은 완전히 올바른 행동입니다. 그러나 라이브러리의 관점에서 현재 동작이 유지된다면 일반 함수의 컨텍스트에서 ! 의 사용이 매우 제한될 것입니다.

다음 코드는

#![feature(never_type)]

fn with_print<T>(i:i32, r:T) -> T {
    println!("{}", i);
    r
}


fn main() {
    #[allow(unreachable_code)]
    *with_print(10,&return)
}

10 인쇄합니까? 지금은 아무 것도 인쇄하지 않습니다. 또는 return 가 인쇄될 때까지 지연되는 다른 해결 방법이 있습니까?

내 말은, 내가 전에 말했듯이 실제로 ! 유형에는 두 가지 다른 종류가 있습니다. 하나는 게으르고 다른 하나는 열망입니다. 일반적인 표기법은 열망하는 것을 나타내지만 때로는 게으른 표기법이 필요할 수도 있습니다.

@RalfJung 이 &return 를 사용하는 이전 버전에 관심이 있어서 코드를 다시 조정했습니다. 그리고 다시, 제 요점은 우리가 나중에 return 를 연기할 수 있어야 한다는 것입니다. 여기서 클로저를 사용할 수 있지만 return 만 사용할 수 있고 break 또는 continue 등은 사용할 수 없습니다.

예를 들어 다음과 같이 쓸 수 있다면 좋을 것입니다.

#![feature(never_type)]

fn with_print<T>(i:i32, r:T) -> T {
    println!("{}", i);
    r
}


fn main() {
    for i in 1..10 {
        if i==5 { with_print(i, /* delay */break) }
        with_print(i, i);
    }
}

5 가 인쇄될 때까지 중단이 지연됩니다.

@earthengine 아니요. 아무 것도 인쇄하지 않아야 합니다. ! 은(는) 사람이 거주하지 않으므로 ! 유형의 값을 만들 수 없습니다. 따라서 ! 유형의 값에 대한 참조가 있으면 데드 코드 블록 내부에 있는 것입니다.

return type이 ! 것은 분기하기 때문입니다. return 표현식의 결과를 사용하는 코드는 return "완료"되지 않기 때문에 실행할 수 없습니다.

oO &return 쓸 수 있는지 몰랐습니다. 말이 안되는데 왜 return 의 주소를 허용해야 합니까?^^

그러나 어쨌든 코드의 @earthengine 에서 인수는 quit_with_print 가 호출되기 전에 평가됩니다. 두 번째 인수를 평가하면 return 가 실행되어 프로그램이 종료됩니다. 이것은 foo({ return; 2 }) -- foo 는 실행되지 않는 것과 같습니다.

@RalfJung return 는 break 또는 continue 와 같은 break ! 유형의 표현식입니다. 유형이 있지만 그 유형은 무인도입니다.

! 이(가) 구현되어 이제 1년 동안 야간 작업을 하고 있습니다. 안정화를 위해 무엇을 해야 하는지 알고 싶습니다.

해결되지 않은 한 가지는 ! (예: uninitialized , ptr::read 및 transmute )를 반환할 수 있는 내장 함수에 대해 수행할 작업입니다. uninitialized , 마지막으로 MaybeUninit 유형과 가능한 미래 &in , &out , &uninit 를 위해 더 이상 사용되지 않아야 한다는 합의가 있다고 들었습니다 Inhabited 특성을 구현하지 않는 유형에 대해서만 uninitialized 사용 중단을 제안한 이전 RFC 가 있지만 이에 대한 uninitialized " 및 "add MaybeUninit " RFC로 대체해야 합니까?

ptr::read 경우 UB로 두는 것이 좋습니다. 누군가 ptr::read 를 호출하면 읽고 있는 데이터가 유효하다고 주장하고 ! 경우에는 확실히 그렇지 않습니다. 어쩌면 누군가가 이것에 대해 더 미묘한 의견을 가지고 있습니까?

transmute 것은 쉽습니다. (현재처럼 ICEing 대신에) 사람이 거주하지 않는 유형으로 변환하는 오류를 만들면 됩니다. 이 문제를 해결하기 위한 PR 이 있었지만 초기화되지 않은 데이터를 처리하는 방법에 대한 더 나은 아이디어가 여전히 필요한 이유로 종료되었습니다.

지금 우리는 이것들과 함께 어디에 있습니까? (/cc @nikomatsakis)? uninitialized 를 더 이상 사용하지 않고 MaybeUninit 유형을 추가하여 앞으로 나아갈 준비가 되셨습니까? ! 호출할 때 이러한 내장 함수를 패닉 상태로 만들면 ! 를 안정화할 수 있는 적절한 임시 조치가 될까요?

보류 중인 문제도 나열되어 있습니다.

! 대해 어떤 특성을 구현해야 합니까? 초기 PR #35162에는 Ord 및 기타 몇 가지가 포함됩니다. 이것은 아마도 T-libs 문제일 것이므로 해당 태그를 문제에 추가하고 있습니다.

현재 상당히 기본적인 선택이 있습니다: PartialEq , Eq , PartialOrd , Ord , Debug , Display , Error . 분명히 그 목록에 추가되어야 하는 Clone 외에 매우 중요한 다른 것을 볼 수 없습니다. 안정화를 차단해야 합니까? 나중에 적합하다고 판단되면 더 많은 impl을 추가할 수 있습니다.

(): Trait 대체에 의존하는 사람들에 대한 경고를 구현하는 방법은 미래에 그 동작이 변경될 수 있습니다.

resolve_trait_on_defaulted_unit 경고가 구현되었으며 이미 안정적입니다.

강제로 ! 에 대한 원하는 의미 체계(#40800)
! 대체해야 하는 유형 변수(#40801)

이것들은 진짜 차단기처럼 보입니다. @nikomatsakis : 구현을 기다리고 있는 이들에 대해 무엇을 해야 하는지에 대한 구체적인 아이디어가 있습니까?

! 가 Sync 및 Send 도 구현하는 것이 의미가 있습니까? 오류 유형에 Sync 및/또는 Send 경계가 있는 여러 경우가 있으며, 여기서 ! 를 "실패할 수 없음"으로 사용하는 것이 유용합니다.

@canndrew 안전하지 않은 코드에서 금지하는 데 동의하지 않습니다. unreachable 크레이트는 변환을 사용하여 무인 유형을 생성하므로 특정 코드 분기가 발생할 수 없도록 최적화 도구를 암시합니다. 이것은 최적화에 유용합니다. 이런 기술을 이용해 재미있는 방식으로 나만의 상자를 만들 계획입니다.

@Kixunil 여기에서 https://doc.rust-lang.org/beta/std/intrinsics/fn.unreachable.html 을 사용하는 것이 더 명확하지 않을까요 ?

@RalfJung 그럴 것이지만 불안정합니다. 사람이 살지 않는 유형으로 변환하는 것을 금지하는 것은 획기적인 변화가 될 것임을 상기시킵니다.

@jsgf 죄송합니다. 예, ! 또한 모든 마커 특성( Send , Sync , Copy , Sized )을 의미합니다.

@Kixunil 흠, unreachable 내장을 안정화하는 것이 훨씬 낫습니다.

안정화 차단기는 아니지만(의미론이 아니라 성능이기 때문에) Result<T, !> 이 enum 레이아웃에서 ! 의 무인도를 사용하지 않거나 codegen 일치: https://github.com /rust-lang/rust/issues/43278

이것은 너무 막연한 생각이어서 여기에 빠뜨린 것에 대해 거의 죄책감을 느끼지만:

분필 이 !: Trait 구현과 관련하여 더 어려운 질문에 답하는 데 도움이 될 수 있습니까?

@ExpHP 저는 그렇게 생각하지 않습니다. 연관된 유형/const가 없고 정적이 아닌 메서드만 있는 특성에 대해 !: Trait 자동 구현은 건전한 것으로 알려져 있습니다. 우리가 하고 싶은지 아닌지의 문제일 뿐입니다. 다른 특성에 대한 자동 구현은 실제로 의미가 없습니다. 컴파일러가 연결된 유형/상수에 대해 임의의 값을 삽입하고 자체 임의의 정적 메서드 impls를 발명해야 하기 때문입니다.

Rustc에는 이미 resolve-trait-on-defaulted-unit 보푸라기가 있습니다. 해당 항목에 체크 표시를 해야 합니까?

@canndrew 관련 유형을 ! 로 설정하는 것이 건전하지 않습니까?

@taralx 건전하지 않지만 유효한 코드가 작동하지 못하게 합니다. 다음 코드가 오늘 컴파일됩니다.

trait Foo {
    type Bar;
    fn make_bar() -> Self::Bar;
}

impl Foo for ! {
    type Bar = (i32, bool);
    fn make_bar() -> Self::Bar { (42, true) }
}

@lfairy "유효한"코드가 무엇인지에 대한 귀하의 의견에 달려 있습니다. 저에게는 ! 에서 아무 것도 얻을 수 없어야 하므로 귀하가 제공한 코드가 "유효하지 않음"이라는 사실을 기꺼이 받아들이겠습니다.

@earthengine 나는 당신이 만들려는 요점을 알지 못합니다. 인스턴스 없이 형식에 대해 정적 메서드를 호출할 수 있습니다. ! 에서 "무엇이든 얻을 수 있는지" 여부는 그것과 관련이 없습니다.

! type 에서 아무것도 얻을 수 없어야 할 이유가 없습니다. 당신은에서 아무것도 얻을 수 없다 ! 에 비 정적 메서드 이유입니다,하지만 ! 프로그래머에 어떤 결정을 시작하지 않고 유도 할 수있다.

나는 규칙이 정확히 1 유효 구현이 존재하는 어떤 특성 (보다 더 많은 차이를 추가 할 것들 제외 구현 될 것입니다 기억하기 쉬운 생각 ! 이미 범위의 원인을).

우리가 사용하는 모든 것은 그것과 같거나 더 보수적이어야 합니다(자동 impls도 적합하지 않음).

@Ericson2314 그게 무슨 뜻인지 이해가

@SimonSapin "no more divergence" 규칙은 panic!() 또는 loop { } 을 의미하지만 이미 범위에 있는 v: ! 는 괜찮습니다. 이러한 식을 제외하면 많은 특성에 에 대한 가능한 함축이 하나만 있습니다. 그 유형 검사. (다른 사람들은 1개 impl을 제외한 모든 것을 배제하는 비공식 계약을 할 수 있지만 우리는 그것들을 자동으로 처리할 수 없습니다.)

// two implementations: constant functions returning true and false.
// And infinitely more with side effects taken into account.
trait Foo { fn() -> bool }

// Exactly one implementation because the body is unreachable no matter what.
trait Bar { fn(Self) -> Self }

수학적으로 말하면 ! 는 "초기 요소"입니다. 즉, 인수에 ! 가 있는 형식 서명의 경우 정확히 하나의 구현이 있습니다. 즉, 모든 구현이 동일합니다. 외부에서 관찰됩니다. 모두 호출할 수 없기 때문입니다.

실제로 안정화를 방해하는 것은 무엇입니까? 단지 mem::uninitialized 상황입니까 아니면 다른 것입니까?

@arielb1 : #40800 과 #40801 도 마찬가지인 것 같아요. 이것들이 어떤 상태인지 아십니까?

이에 대해 어떤 문서가 작성되었거나 사람들이 이에 대해 작성할 계획입니까? std 문서(#43529, #43560)의 기본 유형 페이지에 최근 추가된 사항으로 ! 거기에 페이지를 입력 하시겠습니까? 아직 업데이트되지 않은 경우 참조도 업데이트되어야 합니다.

asm이 분기되어 다음과 같은 것을 작성할 수 있도록 지정할 계획이 있습니까?

#[naked]
unsafe fn error() -> !{
  asm!("hlt");
}

유형 검사기를 달래기 위해 loop{} 를 사용할 필요 없이?

편집: core::intrinsics::unreachable 를 사용하는 것이 매우 낮은 수준의 코드에서 허용될 수 있다고 생각하지만.

@Eroc33 ! 가 유형이면 다음을 수행할 수 있습니다.

#[naked]
unsafe fn error() -> ! {
  asm!("hlt");
  std::mem::uninitialized()
}

그때까지는 다음을 수행할 수 있습니다.

#[naked]
unsafe fn error() -> ! {
  asm!("hlt");

  enum Never {}
  let never: Never = std::mem::uninitialized();
  match never {}
}

@Kixunil ! 는 asm! 를 사용해야 하는 nightly 유형입니다. 이것은 일반적으로 다음과 같이 수행됩니다.

#[naked]
unsafe fn error() -> ! {
    asm!("hlt");
    std::intrinsics::unreachable();
}

@Kixunil std::intrinics::unreachable() 를 사용하면 이전 코드가 분기됨을 정확히 지정하여 더 쉽게 수행할 수 있습니다.

@Kixunil 위의 토론에서 std::mem::uninitialized 는 ! 를 반환할 수 있지만 변경될 수 있는 것처럼 보입니까? 내가 잘못 이해한게 아니라면?

위의 토론에서 std::mem::uninitialized 는 ! 를 반환할 수 있지만 변경될 수 있는 것처럼 보입니까? 내가 잘못 이해한게 아니라면?

uninitialized 는 결국 완전히 더 이상 사용되지 않을 것이며 ! 와 함께 사용하면 중지 간격으로 런타임에 패닉 상태가 될 것이라고 생각합니다(이 경우에는 영향을 미치지 않음).

또한 std::intrinsics::unreachable 를 libcore 어딘가에 안정화하고 unchecked_unreachable 또는 unreachable! 매크로와 구별할 수 있는 이름을 지정해야 한다고 생각합니다. 나는 그것을 위해 RFC를 작성하려고 했습니다.

@eddyb 아, asm!() 가 불안정하다는 사실을 잊어버렸 으니 std::intrinsics::unreachable() 도 사용할 수 있습니다.

@tbu- 물론, 나는 무인도를 만드는 것보다 그것을 선호합니다. 문제는 불안정하기 때문에 코드 분기를 연결할 수 없는 것으로 안전하지 않게 표시하는 것이 어떻게든 불가능하다면 기존 코드가 손상될 뿐만 아니라 수정할 수 없게 된다는 것입니다. 나는 그러한 것이 Rust 평판에 심각한 해를 끼칠 것이라고 생각합니다(특히 안정적이라고 자랑스럽게 주장하는 주요 개발자를 고려하면). 내가 Rust를 사랑하는 만큼 Rust가 유용한 언어라는 것을 다시 생각하게 만들 것입니다.

@Eroc33 내 이해는 어떤 사람들은 그것을 제안하지만 확실한 결정이 아닌 단순한 제안입니다. 그리고 나는 그러한 제안에 반대합니다. 왜냐하면 그것이 역호환성을 깨고 Rust가 2.0이 되도록 할 것이기 때문입니다. 지지하는 데에는 지장이 없다고 생각합니다. 사람들이 버그를 걱정한다면 린트가 더 적절할 것입니다.

@canndrew uninitialized 가 더 이상 사용되지 않을 것이라고 생각하는 이유는 무엇입니까? 나는 그런 것을 믿을 수 없다. 나는 그것이 매우 유용하다고 생각하므로 아주 좋은 대체품이 없다면 그렇게 할 이유가 없습니다.

마지막으로 intrinsics::unreachable() 가 현재의 해킹보다 낫다는 데 동의한다는 점을 거듭 강조하고 싶습니다. 즉, 나는 충분한 대체품이 있을 때까지 이러한 해킹을 금지하거나 사용하지 않는 것에 반대합니다.

초기화되지 않은 것에 대한 대체는 합집합 { !, T }입니다. 당신은 도달 할 수 없습니다
ptr::read::<*const !>()ing 및 기타 유사한 방법이 많이 있습니다.

2017년 8월 8일 오후 3시 58분, "Martin Habovštiak" [email protected]
썼다:

@eddyb https://github.com/eddyb 아, 그래, asm을 잊었다!()는
불안정하므로 std::intrinsics::unreachable() 도 사용할 수 있습니다.

@tbu- https://github.com/tbu- 물론입니다.
무인형 생성. 문제는 불안정하기 때문에
코드의 분기를 연결할 수 없는 것으로 안전하지 않게 표시하는 것은 어떻게 든 불가능합니다.
기존 코드를 깨뜨릴 뿐 아니라 수정할 수 없게 만듭니다. 나는 그런 것을 생각한다
Rust 평판에 심각한 해를 끼칠 수 있습니다(특히 주요 개발자를
안정적이라고 자랑스럽게 주장). 내가 Rust를 사랑하는 만큼, 그런 일은
유용한 언어라는 것을 다시 생각하게 해주세요.

@Eroc33 https://github.com/eroc33 내 이해는 어떤 사람들은
해보라고 제안하지만 확실한 결정은 아닌 제안에 불과합니다. 그리고 나
이전 버전과의 호환성을 깨뜨릴 수 있으므로 그러한 제안에 반대합니다.
Rust를 2.0으로 만듭니다. 지지하는 데에는 지장이 없다고 생각합니다.
사람들이 버그를 걱정한다면 린트가 더 적절할 것입니다.

@canndrew https://github.com/canndrew 왜 초기화되지 않았다고 생각 하세요 ?
더 이상 사용되지 않습니까? 나는 그런 것을 믿을 수 없다. 나는 그것이 매우 유용하다고 생각한다.
그래서 아주 좋은 대체품이 없는 한,
그렇게하고있다.

마지막으로, 내장 함수::unreachable()
현재 해킹보다 낫습니다. 즉, 나는 금지하거나 심지어는
충분한 교체가 있을 때까지 이러한 해킹을 더 이상 사용하지 않습니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/35121#issuecomment-320948013 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AApc0iEK3vInreO03Bt6L3EAByBHQCv9ks5sWFt3gaJpZM4JYi9D
.

@nagisa 감사합니다! 기술적으로 문제를 해결할 수 있을 것 같습니다.

! 가 반환 유형에서 유형 매개변수로 사용될 수 있도록 이것의 하위 집합을 조각할 수 있습니까? 지금 당장 안정적인 기능이 있다면

fn foo() -> ! { ··· }

그리고 ? 사용하려면 일반적인 변환을 수행할 수 없습니다.

fn foo() -> io::Result<!> { ··· }

까다로운 강제 및 유형 매개 변수 기본 질문이 해당 경우에 영향을 줍니까?

match es의 경우 https://public.etherpad-mozilla.org/p/rust-compiler-design-sprint-paris-2017-ucg를 참조

40801 체크할 수 있습니다.

! 안정화하기 전에 #43061 을 수정해야 합니다.

나는 Never_type을 언급하는 미해결 I-불건전한 문제를 보지 못했기 때문에 이에 대한 새로운 문제를 제출했습니다: #47563. [!; 0] 은 사람이 살지 않는다고 가정하는 것 같지만 간단한 [] 만들 수 있습니다.

@dtolnay 가 이슈 헤더에 추가됨

@canndrew 시간 잘 ! 사용량의 하위 집합이 안정화되기를 바랍니다(완벽한 규칙 제외). 하지만 우리가 어디에 있는지에 대한 실마리를 잃어버렸고 챔피언이 필요하다고 생각합니다. 당신은 그 사람이 될 시간이 있습니까?

@nikomatsakis 이 작업에 시간을 할애할 수 있을

@varkor는 이미 나머지 문제를 해결하기 위해 PR을 열어

또 다른 것이지만: 런타임에 mem::uninitialized::<!>() 패닉을 만들고 싶습니까(현재 UB를 유발함)? 아니면 지금은 그런 종류의 변경 사항을 그대로 두어야 합니까? 안전하지 않은 코드 가이드라인에 대한 최신 정보가 아닙니다.

나는 계획이 여전히 https://github.com/rust-lang/rfcs/pull/1892 라고 생각합니다. :)

@RalfJung 특별히 막는 부분이 있나요? 나는 추가 오늘 PR를 작성할 수 MaybeUninit 하고 deprecates uninitialized .

@canndrew 많은 프로젝트가 세 가지 릴리스 채널을 모두 지원하기를 원하고 uninitialized 가 안정 버전에서 사용 가능하기 때문에 안정 채널에서 교체를 사용할 수 있게 된 후에만 Nightly에서 사용 중단 경고를 내보내는 것이 좋습니다. 문서 주석을 통한 부드러운 비추천은 괜찮습니다.

! 안정화를 위한 PR을 만들었습니다 : https://github.com/rust-lang/rust/pull/47630. 아직 병합할 준비가 되었는지 모르겠습니다. 우리는 적어도 @varkor 의 PR이 나머지 미해결 문제를 해결하는지 확인하기 위해 기다려야 합니다.

또한 사람들이 ! 대한 우아한 특성 impls를 작성할 수 있도록 https://github.com/rust-lang/rfcs/pull/1699 를 다시 방문해야 한다고 생각합니다.

@canndrew : 비록 그 RFC가 받아들여지지 않았지만, https://github.com/rust-lang/rust/issues/20021 의 제안과 매우 유사해 보입니다

https://github.com/rust-lang/rust/issues/36479 도 이슈 헤더에 추가되어야 합니다.

@varkor 그것은 매우 유사합니다. 연결할 수 없는 코드 작업을 수행할 때 다음과 같은 코드에 연결할 수 없는 것으로 표시되는 문제를 발견하셨습니까?:

impl fmt::Debug for ! {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        *self    // unreachable!
    }
}

그런 제안을 받아들여야 하기 때문입니다.

@canndrew 제가 최근에 옹호해 온 것은 아직 공식적인 템플릿을 개발하지 않았지만 우리가 안정화하려는 항목을 명확하게 설명하려는 일종의 "요약 문제"입니다. RFC 이후 의 보고서로 생각할 수 있습니다. 안정화되고 있는 것과 그렇지 않은 것의 두드러진 특징을 일종의 총알 목록 형식으로 요약하려고 합니다.

이것의 일부는 문제의 동작을 보여주는 테스트 케이스에 대한 포인터가 될 것입니다.

당신은 그런 것을 그릴 수 있다고 생각합니까? 일종의 "개요"가 마음에 들면 함께 이야기를 나눌 수 있습니다. 아니면 제가 스케치해 볼 수도 있습니다.

관련 질문: 안정화되기 전에 https://github.com/rust-lang/rust/issues/46325 를 해결해야 합니까? 중요하지 않을 수도 있습니다.

@nikomatsakis 경고만 있는 문제가 해결될 때까지 기다리지 않기 위해 투표합니다. 그것은 무해하다. 더 이상 실질적인 우려가 나타나지 않는다면 우리가 진행하고 안정화해야 한다고 생각합니다.

@canndrew : 실제로 그런 경우를 본 적은 없는 것 같지만, ! 가 안정화되면 불가능한 구현을 생략할 수 있는 것이 매우 필요하다고 생각합니다.

@nikomatsakis

당신은 그런 것을 그릴 수 있다고 생각합니까? 일종의 "개요"가 마음에 들면 함께 이야기를 나눌 수 있습니다. 아니면 제가 스케치해 볼 수도 있습니다.

나는 최소한 초안을 작성할 수 있고 그것이 당신이 염두에 둔 것이면 나에게 말할 수 있습니다. 앞으로 이틀에 걸쳐 완료하도록 노력하겠습니다.

@nikomatsakis 이런게 있나요?

요약 문제 - ! 안정화

안정화되고 있는 것

• ! 는 이제 본격적인 유형이며 이제 모든 유형 위치에서 사용할 수 있습니다(예: RFC 1216 ). ! 유형은 다른 유형으로 강제 변환될 수 있습니다. 예를 보려면 https://github.com/rust-lang/rust/tree/master/src/test/run-fail/adjust_never.rs 를 참조

• 형식 유추는 이제 제한되지 않은 형식 변수를 ! 대신 () 합니다. resolve_trait_on_defaulted_unit 린트가 사용 중지되었습니다. 이것이 나타나는 예는 다음과 같은 경우입니다.

  // We didn't specify the type of `x`. Under some circumstances, type inference
  // will pick a type for us rather than erroring
  let x = Deserialize::deserialize(data);
  

  이전 규칙에서는 () 를 역직렬화하지만 새 규칙에서는 ! 역직렬화합니다.

• never_type 기능 게이트는 안정적이지만 게이트에 사용된 일부 동작은 이제 새로운 exhaustive_patterns 기능 게이트 뒤에 있습니다(아래 참조).

안정화 되지 않는 것

• 무인도 유형에 대한 철저한 패턴 매칭. 예를 들어

  let x: Result<u32, !> = ...;
  let Ok(y) = x;
  

  이 코드는 여전히 Ok(_) 가 반박 가능한 패턴이라고 불평합니다. 이것은 exhaustive_patterns 기능 게이트를 사용하여 수정할 수 있습니다. 이 문제에 대한 진행 상황은 RFC 1872 를 참조하십시오. 이 동작이 여전히 게이트임을 확인하는 테스트 케이스는 https://github.com/rust-lang/rust/tree/master/src/test/ui/feature-gate-exhaustive-patterns.rs 를 참조

안정화되기 전에 #46325를 해결해야 합니까?

이렇게 모든 느슨한 끝을 청소하는 것이 좋지만 실제로는 차단기처럼 보이지 않습니다.

@canndrew

이 같은?

네, 감사합니다! 대단해.

누락된 주요 사항은 ! 작동 방식을 보여주는 테스트 사례에 대한 포인터입니다. 청중은 랭 팀이나 밀접하게 따르는 다른 사람들이어야 합니다. 제 생각에는 "범용" 사람들을 대상으로 하는 것이 아닙니다. 예를 들어 강제가 합법이거나 ! 가 사용될 수 있는 곳의 몇 가지 예를 원합니다. 또한 완전한 패턴 일치(기능 게이트가 활성화되지 않은 상태)가 여전히 작동함을 보여주는 테스트를 보고 싶습니다. 이들은 저장소에 대한 포인터여야 합니다.

@canndrew

이렇게 모든 느슨한 끝을 청소하는 것이 좋지만 실제로는 차단기처럼 보이지 않습니다.

글쎄, 그것은 우리가 즉시 행동을 변경하는 새로운 코드를 활성화할 것임을 의미합니다(예: let x: ! = ... 는 일부 표현식에 대해 다르게 행동할 것이라고 생각합니다). 우리가 할 수 있다면 해결하는 것이 가장 좋은 것 같습니다. 열려 있는 PR에서 하드 오류로 만들 수 있고 PR에서 실행되는 기존 분화구와 함께 일괄 처리할 수 있습니까?

@nikomatsakis 몇 가지 링크와 예제로 요약 문제를 다시 업데이트했습니다. 또한, 여기까지 하는 데 시간이 좀 걸리게 된 점 죄송합니다. 지난 주에 매우 바빴습니다.

열려 있는 PR에서 하드 오류로 만들 수 있고 PR에서 실행되는 기존 분화구와 함께 일괄 처리할 수 있습니까?

완료.

@rfcbot fcp 병합

여기에 설명된 대로 ! 유형 또는 그 일부를 안정화 할 것을 제안합니다. 홍보가 여기 있습니다 .

내가 원하는 데이터 중 하나는 분화구 실행입니다. 저는 https://github.com/rust-lang/rust/pull/47630(@canndrew 가 지금 ping에 응답하지 않기 때문에)을 리베이스하는 중이므로 해당 데이터를 얻을 수 있습니다.

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

• [x] @키문디
• [x] @alexcrichton
• [ ] @아투론
• [x] @cramertj
• [x] @dtolnay
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [ ] @pnkfelix
• [x] @sfackler
• [x] @withoutboats

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

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

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

아, 방금 기억나는 몇 가지:

• 우리는 새로운 시대에만 이것을 안정화하는 아이디어를 고려해야 합니다. 특히, 대체 규칙에 대한 변경은 이전 버전과 호환되지 않습니다. 크레이터 실행은 낙진에 대한 일종의 하한을 제공하지만 하한일 뿐입니다. 그러나 새로운 시대에 있지 않는 한 이전 대체 규칙을 유지할 수 있습니다.
• 둘째, 여기 계획의 일부는 ! 대한 특성을 구현하는 것이 적절한 시기에 대한 몇 가지 지침도 포함하는 것이었습니다. TL;DR은 ! 값을 먼저 제공하지 않고 트레이트의 메소드를 사용할 수 없어도 괜찮다는 것입니다 -- 그래서 Clone 대해 ! Clone 를 구현하는 것은 괜찮다고 생각합니다. , 하지만 Default 구현은 그렇지 않습니다. 다시 말해서, impl을 구현하기 위해 무차별적으로 panic! 를 요구한다면 그것은 나쁜 징조입니다. =)

@nikomatsakis 새 시대에 대체 규칙을 변경할 수 있지만 여전히 ! 를 2015 시대에 사용할 수 있는 유형으로 만들 수 있습니까?

@nikomatsakis

우리는 새로운 시대에만 이것을 안정화하는 아이디어를 고려해야 합니다.

지난번에 우리가 분화구를 돌았을 때(오래 전이었습니다) 대체 규칙 변경으로 인한 영향은 상당히 적었습니다. 우리는 또한 한동안 변경의 영향을 받을 수 있는 코드에 대해 linting했습니다.

둘째, 여기 계획의 일부는 ! 대한 특성을 구현하는 것이 적절한 시기에 대한 몇 가지 지침도 포함하는 것이었습니다.

이것은 ! 에 .

@SimonSapin

새로운 시대에 대체 규칙을 변경할 수 있지만 여전히 ! 2015 시대에 사용 가능한 유형으로?

예

@canndrew

지난번에 우리가 분화구를 돌았을 때(오래 전이었습니다) 대체 규칙 변경으로 인한 영향은 상당히 적었습니다. 우리는 또한 한동안 변경의 영향을 받을 수 있는 코드에 대해 linting했습니다.

네. 분화구가 무엇을 말하는지 봅시다. 그러나 내가 말했듯이 분화구는 우리에게 하한선 만 제공합니다. 이것은 일종의 "선택적 변화"입니다. 그래도 나는 당신이 옳다고 생각하며 우리는 야생의 코드에 큰 영향을 미치지 않고 이것을 변경함으로써 "도망갈" 수 있습니다.

TL;DR은 ! 값을 먼저 제공하지 않고 트레잇의 메소드를 사용할 수 없어도 괜찮다는 것입니다.

그것은 정상적인 규칙입니다. "제정신 방식으로 구현"은 패닉을 제외하지만 유효하지 않은 데이터가 있는 경우 "예외" UB를 포함하는 정상적인 방식으로 구현할 수 있을 때 impl을 추가합니다.

@arielb1 예, 하지만 어떤 이유에서인지 사람들은 ! 가 있을 때 이와 같은 것에 대해 혼동하는 경향이 있으므로 명시적으로 호출할 가치가 있는 것 같습니다.

도달할 수 없는 코드 등을 libstd 어딘가에 표현하는 안전한 방법으로 문서화된 안전한 방법 fn absurd(x: !) -> ! 을 갖는 것이 도움이 될까요? 나는 그것에 대한 RFC가 있다고 생각합니다 ... 또는 적어도 RFC 문제 : https://github.com/rust-lang/rfcs/issues/1385

@RalfJung absurd 함수는 그냥 identity 아닌가요? 왜 유용한가요?

인수를 사용하지 않고 매우 정의되지 않은 동작인 unsafe fn unreachable() -> ! 내장과 동일하지 않습니다.

네, 대부분 그렇습니다. 나는 "종료하지 않는다"는 의미에서 ! 반환 유형을 사용하고 있었습니다. ( absurd 의 일반적인 유형은 fn absurd<T>(x: !) -> T 이지만 Rust에서도 유용하지 않은 것 같습니다.)

나는 이것이 "사람들이 ! 가 있는 상황에서 이와 같은 일에 대해 혼란스러워하는 경향이 있다"는 데 도움이 될 것이라고 생각했습니다. "이외의" 추론이 문제가 되는 문서가 어딘가에 있어야 합니다.

나도 잘못된 문제를 가지고있는 것 같습니다 ... 어딘가에서 그런 "ex falso"기능에 대한 토론이 있다고 생각했습니다. 제가 잘못 알고 있는 것 같습니다.

fn absurd<T>(x: !) -> T 도 match x {} 로 쓸 수 있지만 이전에 본 적이 없다면 생각해 내기 어렵습니다. 그것은 적어도 Rustdoc과 책에서 지적할 가치가 있습니다.

fn 터무니없는(x: !) -> T도 match x {}로 쓸 수 있지만, 이전에 본 적이 없다면 생각해내기가 어렵습니다.

맞습니다. 그래서 libstd 어딘가에 메소드를 제안했습니다. 가장 좋은 장소가 어디인지 확실하지 않습니다.

absurd 의 좋은 점은 고차 함수에 전달할 수 있다는 것입니다. 이것이 어떻게 필요한지 확실하지 않습니다! wrt 행동합니다. 그래도 통일.

fn absurd<T>(x: !) -> T match x {} 도 쓸 수 있습니다.

x (AFAIK)로 작성할 수도 있습니다. enum 가 비어 있는 경우에만 match 필요합니다.

absurd(x: !) -> T 함수는 고차 함수로 전달하는 데 유용합니다. 예를 들어 선물을 연결할 때 이것이 필요했습니다. 그 중 하나는 오류 유형 ! 이고 다른 하나는 오류 유형 T 입니다. ! 유형의 표현식이 T 로 강제 변환될 수 있지만 ! 와 T 가 통합된다는 의미는 아니므로 때때로 수동으로 유형을 변환합니다.

마찬가지로 Result 와 같은 유형에는 Result<T, !> 를 Result<T, E> 로 변환하는 .infallible() 메서드가 있어야 한다고 생각합니다.

결과 유사 유형에는 결과를 변환하는 .infallible() 메서드가 있어야 합니다.결과적으로.

나는 그러한 메소드가 Result<T, !> -> T 유형을 가질 것으로 예상했을 것입니다.

나는 그러한 메소드가 Result 유형을 가질 것으로 예상했을 것입니다.-> 티.

이것은 unwrap 와 동일하지 않습니까? Err 케이스에 연결할 수 없으므로 패닉이 최적화됩니다.

@Amanieu 요점은 unwrap 를 사용하면 리팩터링 중에 풋건이 추가되고 패닉이 다시 라이브 코드가 되는 일은 줄어듭니다.

unwrap 는 assert 와 같이 읽습니다. -- "런타임 확인 미리"(IIRC에서는 이름을 바꾸자는 제안도 있었지만 너무 늦게 왔습니다... 슬프게도). 런타임 검사를 원하지 않고 필요하다면 infallible 를 사용하여 명시적으로 만들 수 있습니다.

:bell: 위 의 이제 최종 댓글 기간에 접어들었습니다 . :벨:

@rfcbot fcp 취소

@aturon 및 @pnkfelix 는 해당 상자를 선택하지 않았습니다.

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

@rfcbot fcp 병합

https://internals.rust-lang.org/t/psa-tweaks-to-fcp-process/6775

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

• [x] @alexcrichton
• [x] @아투론
• [x] @cramertj
• [x] @dtolnay
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [ ] @pnkfelix
• [x] @sfackler
• [x] @withoutboats

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

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

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

:bell: 위 의 이제 최종 댓글 기간에 접어들었습니다 . :벨:

우리는 오늘 회의에서 이에 대해 논의했습니다. 지금 폴백을 변경할지 아니면 새로운 시대에만 변경할지 고민됩니다. 다양한 포인트를 소개합니다.

변경의 예상 효과는 작습니다. 따라서 현실적으로 이것은 어느 쪽이든 큰 차이가 없습니다. 여기에서 전체 분석을 볼 수 있지만 요약은 다음과 같습니다.

그리고 그것은 두 개의 실제 회귀를 남깁니다. oplog-0.2.0(실제로는 종속성 bson-0.3.2이 끊어짐)과 rspec-1.0.0-beta.4입니다. 운 좋게도 런타임이 아닌 컴파일 시간에 중단되지만 둘 다 이전 대체 동작에 의존하고 있습니다. 이 상자를 수리하기 위해 PR을 제출하겠습니다.

그러나 이것은 여전히 ​​기술적으로 주요 변경 사항(그리고 자발적 변경 사항)입니다. () 가 매우 좋지 않은 선택이고 코드에서 이에 의존하는 경우가 매우 드물다는 점을 제외하고 유형 변수에 대한 대체를 변경 해야 하는 특별한 이유는 없습니다. 우리는 또한 오랫동안 이것에 대해 경고해 왔습니다.

저는 이것이 철학의 문제라고 생각 합니다. 과거에는 필요에 따라 이와 같은 사소한 변경을 했습니다. 그러나 이제 획기적인 메커니즘이 생겼으므로 기술적으로 아무 것도 손상시키지 않고 그러한 전환을 수행할 수 있는 보다 원칙적인 방법을 제공합니다. 원칙적으로 사용하는 것이 가치가 있을 수 있습니다. 반면에, 그것은 때때로 이런 변화를 만들기 위해 몇 년을 기다려야 한다는 것을 의미합니다. 물론 두 버전을 영구적으로 유지해야 하므로 언어 ​​사양 등을 훨씬 더 복잡하게 만듭니다.

약간 삐뚤삐뚤하지만 균형을 생각하고 앞뒤로 흔들려서 현재 계획대로 "그냥 보편적으로 바꾸자"로 기울고 있습니다.

내가 편향되어 있다는 것을 알고 있지만 dyn Trait 및 catch 비해 더 많은 버그 수정으로 대체 동작을 변경하는 것을 봅니다.

게다가 누군가가 이것에 뛰어들어 "아하! Rust는 결국 하위 호환성을 깨뜨렸습니다! 1.0에 도달했을 때 안정성에 대한 약속은 거짓말이었습니다!"라고 말하고 싶어합니다. 그런 다음 이 문제에 대한 매우 사려 깊은 논의는 무시할 만한 실질적인 영향이 있음에도 불구하고 결정이 가볍게 내려지지 않았음을 보여줍니다.

알겠습니다. 그냥 바꾸자고 합니다.

따라서 타협으로, 사람들에게 행동이 변경되었음을 알리는 오류에 대한 유용한 메모를 제공하고 싶습니다. 그럴듯해 보입니다. 아이디어는 다음과 같을 것입니다.

• 우리는 같은 오류가 표시되는 경우 !: Foo 몇 가지 특성에 대해, 그리고 특성이 구현되어 (): Foo , 우리가 완료 대체를 우리가 추가, (우리는 오류보고 코드이 사실을 알 수 있습니다) 추가 노드.

이제 최종 의견 수렴 기간이 완료되었습니다.

상단 게시물의 보류 중인 확인란이 아직 선택되지 않았습니까? 그 목록에 취소된 것이 있습니까?

@earthengine 나는 내가 본 두 가지가 특별히 관련이 있다고 생각하지 않습니다. 최상위 항목에 관해서는, impls 세트에 관해서는 당분간은 결정된 것 같습니다.

기본적으로 매우 최소한의 세트입니다.

@nikomatsakis 여기에서 요약 문제를 만들었습니다. https://github.com/rust-lang/rust/issues/48950

! 유형의 값과 일치하는 패턴을 ! 로 만드는 것에 대한 고려가 있었습니까? (이 문제와 원래 RFC 문제를 통해 빠른 grep을 수행했지만 관련성을 찾지 못했습니다.)

잠재적으로 ! 오류 유형에서 복합 오류 유형을 생성하는 StreamFuture 와 같은 유형에 유용합니다. map_err 에서 ! 패턴을 사용하면 향후 오류 유형이 변경되면 map_err 호출이 잠재적으로 다른 작업을 수행하는 대신 컴파일을 중지합니다.

예를 들어,

let foo: Result<String, (!, String)> = Ok("hello".to_owned());

이렇게 하면 더 명시적으로 작성할 수 있습니다.

let bar: Result<String, String> = foo.map_err(|(!, _)| unreachable!());

잠재적으로 오류가 발생하기 쉬운 대신

let bar: Result<String, String> = foo.map_err(|_| unreachable!());

또는 오류 발생 가능성이 약간 낮습니다.

let bar: Result<String, String> = foo.map_err(|(e, _)| e);

편집: https://github.com/rust-lang/rfcs/pull/1872 다시 읽기 주석은 ! 패턴 도입에 대해 언급합니다. 그것은 순전히 match 표현식의 맥락에서이지만 클로저/함수 인수로 일반화되는지 확실하지 않습니다.

@Nemo157

제작에 대한 고려가 있었습니까 ! 의 값과 일치하는 패턴입니다! 유형?

흥미로운. 내 생각에 그 계획은 단지 당신이 그런 무기를 떠나게 하는 것이었습니다. 이 경우 -- 만약 미래에 유형이 변경된다면 -- 당신의 매치가 이제 더 이상 완전하지 않을 것이기 때문에 여전히 오류가 발생하게 될 것입니다. ! 패턴의 문제는 일치하는 경우 팔이 불가능하다는 것을 의미하므로 약간 어색합니다. 우리는 당신이 실행할 표현식을 요구하지 않음으로써 그것을 설명하고 싶습니다. 그래도 이런 경우는 있을 수 없다고 명시적으로 말할 수 있는 방법이 있으면 좋을 것 같아요.

실제로 도달할 수 없는 패턴 처리를 확장하는 것이 이 문제를 해결하는 대안이 될 수 있습니다. 매치 암이 불가능한 것으로 판명되면 암 내부의 코드를 무시할 수 있습니다. 그럼 당신이있을 때

fn foo() -> Result<String, String> {
    let bar: Result<String, (!, String)> = Ok("hello".to_owned());
    Ok(bar?)
}

이것은 여전히 ​​오늘처럼 확장됩니다 (_이것이 올바른 확장인지 100 % 확신하지는 않지만 충분히 가까운 것 같습니다_)

fn foo() -> Result<String, String> {
    let bar: Result<String, (!, String)> = Ok("hello".to_owned());
    Ok(match Try::into_result(bar) {
        Result::Ok(e) => e,
        Result::Err(e) => return Try::from_err(From::from(e)),
    })
}

그러나 Result::Err 분기는 유형을 검사하지 않으며 오늘 받는 the trait bound `std::string::String: std::convert::From<(!, std::string::String)>` is not satisfied 오류가 발생하지 않습니다.

RFC 1872가 제안한 것과 호환되지 않는다고 생각합니다. 얕은 일치를 수행하는 명시적 arm이 있기 때문에 ! 값의 유효성에 반드시 의존하는 것은 아니며 잠재적으로 해당 분기가 e.0 를 전혀 사용하지 않는 한 연결된 분기를 "안전하게" 실행하십시오.

! 는 bool 와 같은 포지티브 유형이므로 여러 분기를 허용하도록 클로저 구문을 확장하지 않고 클로저 인수 목록에서 패턴 일치를 수행하는 것은 다소 불가능합니다. 예를 들어 아마도 우리는 bool -> u32 클로저가 (추한 가상의 구문) [~ |false| 23, |true| 45 ~] -> u32 와 같이 작성되도록 허용할 수 있습니다. 그러면 모든 빈 유형에서 u32 로의 클로저는 단순히 [~ ~] -> u32 로 작성할 수 있습니다.

원래 예제를 작성하면 unreachable! 사용을 피하기 때문에 foo.map_err(|(e, _)| e) 선호하지만 foo.map_err(|_: (!, _)| unreachable!()) 작성할 수 있습니다.

! 은 긍정적인 유형입니다.

긍정적 인 유형은 무엇을 의미합니까?

여러 분기를 허용하도록 클로저 구문을 확장하지 않고 클로저 인수 목록에서 패턴 일치를 수행하는 것은 다소 불가능합니다.

인수 목록은 이미 반박할 수 없는 하위 패턴을 지원합니다. 예를 들어

let foo: Result<String, ((), String)> = Ok("hello".to_owned());
let bar: Result<String, String> = foo.map_err(|((), s)| s);

나는 ! 유형의 모든 0 값과 일치하는 반박할 수 없는 패턴으로 ! 패턴을 고려할 것입니다. () 는 () 유형.

나는 단지 고려할 것이다! 패턴은 !의 모든 0 값과 일치하는 반박할 수 없는 패턴입니다. 유형, ()과 동일한 () 유형의 모든 1 값과 일치하는 반박할 수 없는 패턴입니다.

글쎄요, 하지만 0 != 1. ;) ! 에 매칭한 후에 어떤 코드도 작성하는 것은 무의미합니다 -- 예를 들어 인수 유형이 (!, i32) 이면 |(!, x)| code_goes_here 는 그 코드가 어쨌든 죽었기 때문에 어리석은 것입니다. x 가 ! 의 요소라는 것을 분명히 하기 위해 |(x, _)| match x {} 를 작성할 것입니다. 또는 위에서 제안한 absurd 함수를 사용하여 |(x, _)| absurd(x) . 아니면 |(x, _)| x.absurd() ?

위에서 @canndrew가 작성한 것과 같이 코드를 작성 하지 않도록 하는 다른 구문을 상상할 수 있습니다. match 에는 여러 가지 분기가 있으므로 특히 분기가 없을 수도 있습니다. 그러나 클로저는 정확히 하나의 경우를 가지므로 의미가 있는 유일한 패턴은 일치하는 방법이 정확히 1개인 패턴입니다. 0 방법이 아닙니다.

지금은 impl<T> From<!> for T 추가할 수 없습니다. ( From<T> for T 와 겹칩니다. 뭔가 전문화되어 있지 않습니까?) 나중에 추가할 수는 없을 것입니다. ( ! 가 안정화된 후 릴리스 주기에서 일부 크레이트는 From<!> for SomeConcreteType 구현할 수 있습니다.)

@SimonSapin 좋은 지적! 이것은 많은 것들에 대해 매우 유용한 빌딩 블록이며, 나는 영원히 그것을 느슨하게 하고 싶지 않습니다. 두 인스턴스를 모두 허용하는 일회성 해킹을 진지하게 고려할 것입니다. 그것들은 겹치는 경우에 의미적으로 일치하므로 "운영상의 일관성"이 없습니다.

일회성 해킹을 진지하게 고려할 것입니다

그런 다음 그 해킹은 앞으로 며칠 안에 착륙해야 합니다. (또는 베타 기간 동안 백포팅됩니다.)

@SimonSapin 그러한 해킹을 얼마나 빠르고 쉽게 추가할 수 있습니까? From<!> for T 를 가질 수 없다는 것은 정말 짜증나는 일입니다.

또는 From<!> for SomeConcreteType 구현에 대한 경고를 빠르게 던질 수 있습니다.

해킹이 무엇인지에 따라 다릅니다. 교차점에 대해 세 번째가 있는 경우 특성 특화를 통해 두 개의 겹치는 impl을 사용할 수 있다고 생각합니다. 하지만 이를 위해서는 특성이 공개적으로 "특화 가능"해야 하나요?

불행히도 전문화:

• From::from 를 default fn 로 변경해야 std 외부에서 "표시"됩니다. 전문화가 불안정한 한 표준 특성에서 그렇게 하고 싶은지 모르겠습니다.
• RFC 1210에서 허용되는 것처럼, 특히 내가 생각했던 언어 기능을 지원하지 않습니다(교차에 대한 세 번째 impl를 작성하여 둘 다 다른 것보다 더 구체적이지 않은 두 개의 겹치는 impl를 명확하게 함).

여기서 두 개의 impls는 정확히 동일한 작업을 수행합니다. 만약 우리가 일관성 검사를 끄면 어떤 impl이 사용되는지 결정하기 어려울 것입니다. 이것은 일반적으로 매우 불건전하지만 이 경우에는 괜찮습니다. 예를 들어 하나의 결과를 기대하는 컴파일에서 약간의 패닉을 일으킬 수 있지만 우리는 그 주위를 해킹할 수 있습니다.

다시 말해, 다행스럽게도 이것이 전문화를 가속화하는 것보다 훨씬 쉽다고 생각합니다.

이 "관련된 모든 impls에 연결할 수 없는 경우 임의의 겹침 허용" 아이디어를 공식화하기 위한 기존 RFC가 있습니까? 고려해 볼 만한 흥미로운 접근 방식인 것 같습니다.

내가 알기로는 아니야. 펜던트 자체는 impl 자체에 도달할 수 없지만 내부 메서드는 모두 호출할 수 없습니다(항상 "호출 가능"하므로 연결된 유형이나 상수가 포함되지 않음). 해킹이 차단된 것으로 판단되면 빠르게 작성할 수 있을 것 같습니다.

문제를 일으킬 수 있는 #49593 문제를 언급하기만 하면 됩니다! 더 나은 찾기를 위해 다시 불안정해집니다.

! 안정화 후 T: From<!> 외에 추가할 수 없는 impls가 궁금합니다. 우리는 안정화되기 전에 이러한 모든 합리적인 impls를 처리하려고 노력해야 할 것입니다. 이러한 러시가 없는 일반적으로 ! 에 대한 impls와 구별됩니다.

이 댓글의 교차 게시:

()에 대한 대체가 변경되어야 하는 이유에 대한 고전적인 예는 무엇인지 궁금합니다. 즉, 계속해서 ()로 대체하지만 여전히 !를 추가하면 그런 종류의 문제를 확실히 피할 수 있고 다시 ! "라이브" 코드에 영향을 주는 유형 변수에 대한 폴백이 발생하는 경우가 있다는 점을 고려하면 최적이 아닙니다(물론 의도는 그렇지 않지만 발견한 대로 누출을 방지하기 어렵습니다).

변경의 결과로 몇 가지 퇴행이 있었고 나는 그것에 완전히 편하지 않다고 말해야 합니다.

• @SimonSapin 은 일부 안전하지 않은 코드가 어떻게 퇴행하여 건전하지 않은지 설명합니다 . 이것은 ! 되돌아갔지만 실제로는 죽은 코드가 아닌 바인딩되지 않은 유형 매개변수 때문이었습니다. 이것은 현재 체계의 알려진 실패이며 match foo { P1 => ..., P2 => return } 가 있을 때 발생합니다. 반환은 다른 팔과 통합되는 " ! 유형 변수로의 폴백"을 생성합니다. 수정하기가 상당히 어렵다는 것이 입증되었습니다. 예를 들어 https://github.com/rust-lang/rust/issues/40801을 참조
• @mitsuhiko 가 이 댓글을 올렸 습니다 .

(이 점에 대해 lang-team 토론을 위해 지명합니다.)

회의 중에 우리는 여기에서 몇 가지 옵션을 철회했습니다. 저는 변경하기를 꺼려합니다. 주로 일부 경우에 기존 코드의 의미를 변경하고 새 규칙이 더 나은지 확실하지 않기 @cramertj 는 변형 사례에서 폴백에 대한 열망을 언급했습니다. 예를 들어 Ok(33) 유형이 현재와 같이 오류가 발생하는 대신 Result<i32, !> 로 폴백됩니다. return 에서 () 로 폴백을 유지하는 것은 이러한 변경(직교적이지만)과 일치하지 않으며 향후 충돌을 일으킬 수 있다고 말한 것 같습니다. 이것은 공정하다.

Err 피드백(#40801)의 문제는 다음과 같은 경우도 있다는 것입니다.

let mut x = Ok(22);
x = Err(Default::default());

여기서 x 은 궁극적으로 Result<T, !> 유추됩니다.

! fallback이 라이브 코드에 "영향을 받은"지 여부를 결정할 수 있는지 확인하고 시도해야 했던 별도의 계획이 생각납니다. 우리가 실제로 많은 경우 @SimonSapin 의 경우).

새 판에서 이 대체를 완전히 제거할 수 있는지에 대한 논의도 있었습니다. 나는 그것이 많은 매크로를 깨뜨릴 것이라고 생각하지만 시도해 볼 가치가 있습니까?

참고로 이 기능은 1.26에서 회귀를 일으켰습니다. #49932

(https://github.com/rust-lang/rust/issues/35121#issuecomment-368669041에 따라 레이블 설정.)

! 로의 강제에 대한 체크리스트 항목이 이 문제를 참조하는 대신 https://github.com/rust-lang/rust/issues/50350을 가리켜야 합니까?

이것이 가능한 한 빨리 안정화되기를 원하면 내 에너지를 어디로 보내는 것이 가장 좋을까요?

@remexre 안정화를 되돌리는 문제에 대한 가장 좋은 설명은 https://github.com/rust-lang/rust/issues/49593에 있다고 생각합니다.

따라서 실행 가능한 솔루션은 특수 케이스 Box를 다음의 하위 유형으로 사용하는 것입니다.
상자? 이 방법으로 처리할 수 없는 객체 안전 특성이 있습니까?

2018년 7월 8일 일요일 오전 8:12 Ralf Jung 알림 @github.com 작성:

@remexre https://github.com/remexre 가장 좋은 설명은
안정화를 되돌리는 문제는 #49593에 있습니다.
https://github.com/rust-lang/rust/issues/49593

—
당신이 언급되었기 때문에 이것을 받는 것입니다.

이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/35121#issuecomment-403286892 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEAJtcnsEaFmHrrlHhuQeVOkR8Djzt50ks5uEgVLgaJpZM4JYi9D
.

>

감사 해요,
나단

해당 토론은 실제로 https://github.com/rust-lang/rust/issues/49593 으로 이동해야 하지만 핵심 부분은 Box::<T>::new 에 T: Sized 가 필요하지만 new 호출된 T = Error (특성 DST)를 갖는 것으로 유추됩니다.

특별한 케이스의 우아함 외에 특별한 케이스 Box::new 에 다음과 같은 문제가 있습니까?

Box::new : T -> Box<U>
where T <: U,
      T: Sized

또는

Box::new : T -> Box<U>
where Box<T> <: Box<U>,
      T: Sized

먼저 ! 의 크기는 얼마가 되어야 하는지 생각해야 합니다. 수학자는 Inf 와 같은 것을 제안하지만 실제로는 usize::MAX 이므로 이 유형에 대한 공간 할당 시도가 실패하거나 최소한 panic 합니다.

! 가 Sized 이면 Box::new(x as !) 를 컴파일하는 것을 막을 수는 없지만 이것은 기본적으로 panic! 또 다른 방법입니다. usize::MAX 바이트를 할당합니다.

! 가 ZST가 되는 것에 비해 무한/ usize::MAX 크기를 가져야 한다는 것이 분명하지 않은 것 같습니다.

use std::mem::size_of;
enum Void {}
fn main() { println!("{}", size_of::<Void>()); }

현재 는 0입니다.

그 이유는 렌더링된 텍스트에 설명되어 있습니다.

bool : 두 개의 유효한 값 => log(2)/log(2) = 1비트
() : 유효한 값 1개 => log(1)/log(2) = 0비트
! : 0 유효한 값 => log(0)/log(2) = Inf 비트

관련 이론에 정통하지 않은 사람으로서 나는 log(x)/log(y) 공식을 고수하여 이론적인 모델의 우아함을 추구하여 실제 사용에 손해를 입히는 것을 봅니다. (일명 자신의 이익을 위해 너무 영리함)

직관적으로 ! 는 다음과 같은 이유로 크기가 0이어야 합니다.

• bool : 두 개의 유효한 값을 구분하기 위한 공간 필요 => log(2)/log(2) = 유형 시스템 외에 1비트
• () : 하나의 유효한 값을 구분하기 위해 공백이 필요함 => 유형 시스템을 넘어서는 공백이 필요하지 않음
• ! : 유효한 값을 구분하기 위해 공백이 필요하지 않음 => 유형 시스템을 넘어서는 공백이 필요하지 않음

음, 실제로는 -무한대입니다. 이는 ! 필드를 구조체로 변환하는 것은 본질적으로 구조체를 ! 뿐만 아니라 (c + -inf = -inf). 그래서 우리는 usize를 다루고 있기 때문에 0은 우리가 그것을 나타내야 하는 가장 가까운 값입니다. (내 생각에 Rustc의 실제 구현은 -inf도 사용합니다.)

직관적으로 ! 도 크기가 0이어야 하는 것처럼 보입니다.

! 는 크기가 전혀 필요하지 않습니다. 해당 유형으로 생성된 값이 없기 때문입니다. 관련 없는 질문입니다.

0 유효한 값 => log(0)/log(2) = Inf 비트

log(0)이 정의되지 않았습니다. 그것은 무한하지 않습니다.

반면에 usize::MAX 크기를 갖는 것은 비거주를 강제하는 의례적인 방법입니다. 동의하다?

@CryZe @varkor

그것은 또한 내 직관이 ! 를 "완전히 다른 수준의 ZST"로 보고 싶어하는 타당성을 추론하려고 했던 개념과 일치합니다. (즉, ! 는 유형 시스템에 대한 것이고 () 는 메모리 할당에 대한 것입니다.)

@CryZe
-Inf + c == -Inf 공식은 의미가 있지만 -Inf 를 0usize 바꾸면 더 이상 유효하지 않습니다.

반면에 산술이 "caped"인 경우 모든 오버플로가 usize::MAX 로 계산되면 usize::MAX 가 공식에 완벽하게 맞습니다.

두뇌 모델: ! 유형의 객체가 있는 경우 이를 포함하는 구조체를 할당하려면 ! 보다 더 큰 구조체가 필요하지만 이미지로 만들 수 있는 가장 큰 구조체 크기는 usize::MAX . 따라서 필요한 공간은 여전히 usize::MAX 입니다.

왜 그냥 "클램프"무효 형이 포함 된 모든 종류의 크기 (안 ! , 또는 사용자 정의 enum Void {} 로) size=0,alignment=0 ? 이것은 나에게 훨씬 더 의미 론적으로 합리적인 것 같습니다 ...

@remexre
이것은 작동하지 않기 때문입니다. 예: sizeof(Result<usize,!>) == sizeof(usize) .

음, Result<usize, !> 에는 ! 직접 포함되지 않습니다. sizeof(Result::Ok(usize)) == 8 , sizeof(Result::Err(!)) == 0

아니, sizeof(Result::Err(!)) == usize::MAX 내 제안에, 때문에 Result::Err(!) :: Result<!,!> .

규칙은 다음과 같아야에 enum S의 크기 ! 다른 모든 크기 값보다 적은 것으로 간주되지만에서 structs , 그것은 최대 크기는 지금까지 이미지 수 있습니다.

결론:

• ! 는 DST가 아닙니다. DST는 크기가 없어서가 아니라 크기 정보가 숨겨져 있기 때문에 Sized 아닙니다. 그러나 ! 대해 우리는 그것에 대해 모든 것을 알고 있습니다.
• ! 는 크기를 조정해야 하므로 Box::new(x as !) 는 최소한 컴파일이 허용되어야 합니다.
• struct s 포함 ! 는 ! 인 것처럼 크기 조정되어야 하고 enum s 는 변형에서 직접 ! 로 크기 조정되어야 합니다. 해당 변형이 존재하지 않는 경우.

sizeof(!)==0 또는 sizeof(!)==usize::MAX 고려하거나 위의 사항을 허용하기 위해 몇 가지 특별한 산술을 도입해야 합니다.

sizeof(!)==0 : 구조체에서, 0 + n = 0 :worried:, 열거형에서, max(0,n) = n : 홍당무:.
sizeof(!)==usize::MAX : 구조체에서 usize::MAX + n =usize::MAX :neutral_face: 열거형에서 max(usize::MAX,n) = n : 플러시:.

usize::MAX 선호하는 이점이 있습니다. 실제 시스템에서는 불가능하기 때문에 unsafe 라도 이러한 객체를 구성하려는 시도를 기술적으로 방지합니다.

usize::MAX에 유리하다는 장점이 있습니다. 실제 시스템에서는 불가능하기 때문에 안전하지 않은 시도라도 그러한 객체를 구성하려는 시도를 기술적으로 방지합니다.

내 말은, unsafe 속임수가 허용되는 경우: *transmute::<Box<usize>, Box<!>>(Box::new(0)) 는 크기에 관계없이 ! 받습니다. usize::MAX 는 누군가가 std::mem::zeroed<!>() 시도하면 컴파일러에서 오류가 발생할 가능성이 더 높지만 수학보다는 안전하지 않은 코드를 작성하는 사람에게 책임이 있습니다. 위의 이상함.

! 크기가 _actually_ 0 -- MAX 또는 -INF -saturated-to-0이 아님 -- 이전과 같이 부분 초기화를 처리하는 데 필요합니다. https://github.com/rust-lang/rust/issues/49298#issuecomment -380844923에서 찾을 수 있습니다(및 https://github.com/rust-lang/rust/pull/50622에서 구현됨).

이것이 작동하는 방식을 변경하려면 새 문제를 만들거나 그에 대한 PR을 작성하십시오. 이것은 장소가 아닙니다.

@remexre

Box::new : T -> Box<U>
where T <: U,
      T: Sized

Box 는 (대부분) 라이브러리 유형이고 new 메서드는 src/liballoc/boxed.rs Rust 구문에 정의되어 있습니다. 귀하의 설명은 Rust에 존재하지 않는 <: 연산자를 가정합니다. 이것은 Rust의 하위 유형이 수명 매개변수를 통해서만 존재하기 때문입니다. 더 읽고 싶거나 보고 싶다면:

• https://doc.rust-lang.org/nomicon/subtyping.html
• https://www.youtube.com/watch?v=fI4RG_uq-WU

! 모든 종류의를 강요 할 수 있지만,이 모든 종류의 것보다 약합니다. (예를 들어, Vec<&'static Foo> 도 Vec<&'a Foo> 에 대해 'a 이지만 Vec<!> 에서 Vec<Foo> 로의 암시적 변환은 없습니다. http:/ /play.rust-lang.org/?gist=82d1c1e1fc707d804a57c483a3e0198f&version=nightly&mode=debug&edition=2015)

unsafe 모드에서 적절하다고 생각하는 모든 것을 할 수 있지만 현명하게 하지 않으면 UB에 직면해야 한다는 생각이 듭니다. ! 의 공식 크기가 usize::MAX 인 경우 사용자에게 이 유형이 인스턴스화되지 않도록 충분히 경고해야 합니다.

또한 얼라이먼트에 대해서도 생각하고 있었습니다. 무인 유형의 크기가 usize::MAX 인 경우 정렬도 usize::MAX 로 설정하는 것이 자연스럽습니다. 이것은 유효한 포인터를 널 포인터로 효과적으로 제한합니다. 그러나 정의상 null 포인터는 유효하지 않으므로 이 유형에 대한 유효한 포인트조차 없으며 이 경우에 완벽합니다.

@ScottAbbey
Box::new(x as !) 문제가 발생하지 않도록 이 문제에 집중하고 있으므로 계속해서 안정화할 수 있습니다. 제안된 방법은 ! 에 크기를 지정하는 것입니다. ZST가 표준이라면 괜찮을 것입니다. 나는 더 이상 논쟁하지 않습니다. sizeof(!)==0 가 실행되도록 구현하면 됩니다.

정렬을 설정하는 것은 자연스럽습니다. 또한 use::MAX를 사용합니다.

usize::MAX 는 2의 거듭제곱이 아니므로 유효한 정렬이 아닙니다. 또한 LLVM은 1 << 29 이상의 정렬을 지원하지 않습니다. 그리고 ! 는 어쨌든 큰 정렬이 없어야 합니다. let x: (!, i32); x.1 = 4; 는 기가바이트 이상이 아니라 4바이트의 스택만 사용해야 하기 때문입니다.

이 토론을 계속하려면 @earthengine 이라는 새 스레드를

여기서 발생하는 문제는 Box::new(!) 가 Box<$0> 이고 여기서 Box<Error> 가 예상된다는 것입니다. 유형 주석이 충분하면 Box<$0> 를 Box<Error> 로 강제 변환해야 합니다. 그러면 나중에 $0 기본값이 ! 됩니다.

그러나 $0 는 유형 변수이므로 강제 변환되지 않고 $0 = Error 를 얻습니다.

문제를 수정하기 위한 한 가지 해킹 옵션은 $0: Sized 제약 조건이 있다는 것을 발견하고 이에 대한 강제 변환을 삽입하여 Box 가 여전히 해당 유형에서 호출되도록 하는 것입니다.

우리는 이미 검출이 같은 것을 할 Fn 이 같은 스트레칭하지 않도록, 폐쇄에 있습니다. 여전히 못생긴.

즉, 강제 실행 중에 Y 가 확실히 크기가 지정되지 않고 $0 가 확실히 크기가 지정되는 $0: Unsize<Y> 형식의 의무가 발생하는 경우 이를 모호성으로 취급하지 말고 오히려 그것을 "ok"로 취급하고 크기가 조정되지 않은 강제로 진행하십시오.

@arielb1

그렇다면 이것은 Box::new(()) to Box<Debug> 강제하는 것과 어떻게 다릅니까? std::error::Error 는 [u8] 와 같은 유형이 아니라 Debug 와 같은 특성입니다. 반면 std::io::Error 는 유형이지만 Sized 입니다.

다음과 같은 문제는 결코 없습니다.

use std::fmt::Debug;

fn f(x:()) -> Box<Debug> {
    Box::new(x)
}

fn main() {
}

@earthengine 이 문제와 코드의 차이점은 다음과 같습니다.

| 서면 | Box::new(!): Box<Debug> | Box::new(()): Box<Debug> |
| ------ | ------ | ------- |
| 수행 | Box::new(! as Debug): Debug | (Box::new(()) as Box<Debug>): Debug |

때문에 기본적으로 ! 아무것도 강요 할 수 있습니다, 그것은 강제 변환됩니다 Debug 호출하기 전에 Box::new . () 옵션이 아니므로 두 번째 경우에는 문제가 없습니다. 강제 변환 은 Box::new 이후에 발생합니다.

@RalfJung

내 두뇌 모델은 DST가 야생에 존재할 수 없다는 것입니다. DST는 좀 더 구체적인 유형에서 가져와야 합니다. 이것은 매개변수 위치에 DST를 허용하는 경우에도 마찬가지입니다(반환 위치가 아닌 경우). 즉, 실제 값이 이미 포인터 뒤에 배치될 때까지는 ! 일지라도 DST에 동조할 수 없어야 합니다.

예를 들어 다음은 컴파일되지 않아야 합니다.

let v: str = !;
let v: [u8] = !;
let v: dyn Debug = !;

단순히 ! 를 기존 Rust 표현식으로 대체하여 컴파일할 수 없기 때문입니다.

편집하다

그것은 () 옵션이 아닙니다

그래서 아무도 이유를 설명할 수 있습니까? () as dyn Debug 가 컴파일되지 않으면 ! as dyn Debug 가 컴파일되지 않으며 그 반대도 마찬가지입니다. &() as &Debug 컴파일하므로 &! as &Debug 하면 문제가 없습니다. () as dyn Debug 가 언젠가 컴파일된다면, 오늘 우리가 가진 문제는 () 대해 반복될 것이므로 DST RFC 구현자는 이에 대한 책임을 져야 하며, 따라서 우리가 가지고 있는 것과 동일한 문제를 해결할 것입니다. ! .

! 는 존재하는 것이 불가능하기 때문에 무엇이든 강제합니다. "엑스 팔로 쿼드리벳". 따라서 모든 예제 는 컴파일

! 도 존재할 수 없기 때문에 "DTS는 존재할 수 없다"를 위반하지도 않습니다. :)

() as dyn Debug 컴파일되지 않음

크기가 조정되지 않은 rvalue에 대한 계획이 무엇인지 모르겠지만 컴파일할 수 있을 것 같습니다.
요점은 ! 이 작업을 수행할 때 크기가 지정되지 않은 rvalue를 구현할 필요가 없다는 것입니다. 이는 죽은 코드에서만 발생할 수 있기 때문입니다.

그러나 아마도 여기에서 가능한 해결책을 가리키고 있을 것입니다(그리고 아마도 그것은 @arielb1 도 위에서 제안한 ! 강제를 제한할 수 있습니까? ? 이렇게 하는 데는 이론적인 이유가 없지만 실용적인 이유가 있습니다. :D 즉, 이 문제를 해결하는 데 도움이 될 수 있습니다.

내가 "DTS는 존재할 수 없다"라고 말했을 때 나는 구문론을 의미합니다. 예를 들어, 입력된 지역 변수가 str 인 것은 불가능합니다.

반면에 ! cannot exist는 의미가 있습니다. 당신은 쓸 수 있습니다

let v = exit(0);

컨텍스트에서 v 구문적으로 ! 로 입력하지만 바인딩이 실행되지도 않아 실제 세계에서 종료되지 않습니다.

이유는 다음과 같습니다. 동일한 유형의 표현식을 작성할 수 있는 경우에만 ! 모든 유형에 대한 강제 변환을 허용합니다. 유형이 구문적으로 존재할 수 없는 경우 허용해서는 안 됩니다.

이것은 크기가 조정되지 않은 rvalue에도 적용되므로 크기가 조정되지 않은 rvalue를 처리하는 방법을 알 때까지 크기가 조정되지 않은 유형에 ! 를 강제하는 것은 허용되지 않습니다. 그리고 그 시점에서만 우리는 이 문제에 대해 생각하기 시작할 수 있습니다(한 가지 분명한 해결책은 Box::new 이 크기가 지정되지 않은 값을 수신하도록 허용하는 것 같습니다).

예를 들어, str이 입력된 지역 변수를 가질 수는 없습니다.

이는 현재 구현의 한계일 뿐입니다. https://github.com/rust-lang/rust/issues/48055

@RalfJung

여기가 문제가 아닙니다.

다시 Box::new(!: $0): Box<dyn fmt::Debug> $0 가 유형 변수인 상황에 있다고 가정합니다.

이어서 컴파일러는 비교적 쉽게 추론 할 수 $0: Sized (인해 $0 의 입력 파라미터와 같은지 Box::new 가지고 T: Sized 행 참조).

문제는 컴파일러가 Box<$0> 를 Box<dyn fmt::Debug> 로 변환하는 데 사용할 강제 유형을 파악해야 하는 경우에 발생합니다. "로컬" POV에는 두 가지 솔루션이 있습니다.

1. CoerceUnsized 강압이 있어야 Box<$0>: CoerceUnsized<Box<dyn fmt::Debug>> 합니다. 이것은 $0 = ! 유효한 프로그램이며 기본값을 지정하면 해당 프로그램으로 컴파일됩니다.
2. $0 = dyn fmt::Debug 하여 ID 강제 변환을 수행합니다. 이는 $0: Sized 요구 사항과 일치하지 않습니다.

컴파일러는 성능 문제와 디버그하기 어려운 문제를 모두 일으킬 수 있으므로 모호성을 고려할 때 너무 많은 항목을 열어 두기를 원하지 않으므로 상당히 어리석은 방식으로 사용할 강제 변환을 선택합니다(특히, T: CoerceUnsized<T> 가 없으므로 컴파일러가 옵션 1을 선택하면 매우 쉽게 "고착"될 수 있으며 결국 옵션 2를 선택하지만 실패합니다. 나는 그것을 조금 더 똑똑하게 만들고 옵션 1을 선택하는 아이디어가있었습니다.

따라서 이 POV에서 생각하면 올바른 아이디어는

1. 크기가 조정되지 않은 강제는 일관성이 있습니다(모호성이 괜찮다는 점을 제외하고는 현재 규칙이 됨).
2. 크기를 지정하지 않은 강제 실행되지 않고있는

$0 = dyn fmt::Debug인 ID 강제 변환이 있습니다. 이는 $0: 크기 요구 사항과 일치하지 않습니다.

나는 왜 우리가 let v: str=! 하지만 let v: str; 는 허용하지 않아야 하는지 거의 알 수 없습니다. 특정 유형의 변수를 선언할 수도 없다면 왜 (아마도 불가능할 수도 있는) 값을 바인딩할 수 있습니까?

크기가 조정되지 않은 rvalue가 제공되지 않을 때 일관된 방법은 크기가 조정되지 않은 유형에 대한 강제를 허용하지 않는 것입니다. 이는 상상에서만 발생하는 경우에도 크기가 조정되지 않은 rvalue(일시적일 수 있음)를 생성하기 때문입니다.

그래서 내 결론은 Box::new(!) as Box<Error> 문제는 ! 유형이 아니라 크기가 조정되지 않은 rvalue에 대한 차단 문제라는 것입니다. ! 강제 규칙은 다음과 같아야 합니다.

let v: T = ! 쓸 수 있는 경우에만 let v: T 를 쓸 수 있습니다.

그러면 실제 의미가 언어로 평가됩니다. 특히, 크기가 조정되지 않은 rvalue가 있는 후에는 Box::new(! as dyn Debug) 있지만 그 전에는 아니오라고 말하고 싶습니다.

그렇다면 앞으로 나아가기 위해 우리는 무엇을 할 수 있습니까?

크기가 지정되지 않은 강제 변환을 트리거하는 기능 게이트를 코드에 추가합니다. 크기가 지정되지 않은 rvalue가 켜져 있으면 이 강제 변환을 시도하고, 그렇지 않으면 건너뜁니다. 이것이 유일하게 사용 가능한 강제 변환인 경우 오류 메시지는 유사한 경우와 같이 "특성 경계 str: std::marker::Sized 가 충족되지 않음"이어야 합니다. 그래서

우리는 이것이 더 큰 기능에서 성능을 망치지 않고 계산될 수 있음을 확인해야 합니다.

간단한 기능 검사만 수행하면 됩니다.

한편, 크기가 조정되지 않은 rvalues ​​에 대한 새 문제를 추가하고 추적 문제에 링크를 추가하여 이 문제가 제대로 해결되었는지 확인하십시오.

흥미롭군.

이것

fn main() {
    let _:str = *"";
}

컴파일하지만

fn main() {
    let v:str = *"";
}

하지 않다. 이것은 ! 유형과도 관련이 없습니다. 이에 대한 문제를 만들까요?

마지막이 정말 버그인지 모르겠습니다. 두 번째 예제는 크기가 지정되지 않은 rvalue 지원이 없으면 컴파일러가 로컬 변수 v 에 할당할 스택 공간의 양을 정적으로 알고 싶어하지만 DST이기 때문에 알 수 없기 때문에 컴파일되지 않습니다.

첫 번째 예에서 _ 패턴은 지역 변수 바인딩과 같은 어떤 것과도 일치할 뿐만 아니라 변수를 전혀 생성하지도 않는다는 점에서 특별합니다. 따라서 해당 코드는 fn main() { *""; } 없이 let 합니다. 참조(DST도 포함)를 역참조한 다음 결과에 대해 아무 것도 하지 않는 것은 유용하지 않지만 유효한 것으로 보이며 유효하지 않아야 한다고 확신하지 않습니다.

오른쪽. 그러나 특히 다음과 같이 정말 혼란 스럽습니다.

fn main() {
    let _v:str = *"";
}

컴파일하지도 않습니다. _ 에 대한 당신의 이론으로 이것은 우리가 단지 _ 아니라 _v 라고 부르는 것을 제외하고는 동일해야 합니다.

내가 기억하는 바에 따르면 _v 와 v 의 유일한 차이점은 선행 밑줄이 사용되지 않은 값에 대한 경고를 표시하지 않는다는 것입니다.

반면에 _ 특히 "폐기"를 의미하며 패턴(예: 튜플 압축 풀기, 인수 목록 등)에서 두 개 이상의 위치에 나타날 수 있도록 특별히 처리됩니다. 이름 충돌에 대한 오류입니다.

반면에 _는 "폐기"를 의미하며 이름에 대한 오류를 일으키지 않고 패턴(예: 튜플 언팩, 인수 목록 등)에서 둘 이상의 위치에 나타날 수 있도록 특별히 처리됩니다. 충돌.

옳은. 당신이 말한 것 외에도 let _ = foo() 는 drop 가 즉시 호출되는 반면 _v 는 범위를 벗어날 때만 삭제됩니다(예 v 는 ).

사실 이것이 내가 " _ 는 특별하다"는 말의 의미입니다.

따라서 이제는 크기가 조정되지 않은 모든 rvalue를 거부하는 것처럼 보입니다("크기 조정되지 않은 rvalues" 기능이 켜져 있지 않는 한). 비록 효과는 미미할지라도.

그런 다음 ! 에서 크기가 조정되지 않은 rvalue로의 강제 변환을 허용하지 않는 기능 게이트를 사용하는 것이 좋습니다. 이것은 let _:str = return; 와 같은 코드를 거부하지만 아무도 코드에서 이를 사용하지 않을 것이라고 생각합니다.

! 유형이 불안정한 한 강제 변환할 수 있는 부분과 불가능한 부분을 크게 변경할 수 있습니다.

문제는 https://github.com/rust-lang/rust/issues/49593 을 수정하기 위해 DST에 대한 강제 없이 안정화하는 경우 나중에 크기가 조정되지 않은 rvalue를 추가할 때 이러한 강제를 복원하고 싶습니까? https://github.com/rust-lang/rust/issues/49593을 다시 깨지 않고 그렇게 할 수 있습니까?

내 이전 제안에는 이것이 포함되어 있습니다. #49593 은 크기가 조정되지 않은

최종 솔루션에 대한 개인적인 제안은 Box::new (다른 중요한 방법도 포함될 수 있음)가 크기가 조정되지 않은 매개변수를 허용하고 유사한 상황에서 모호성을 허용하도록 하는 것입니다.

FWIW, _ 는 특수 변수 이름 과 다릅니다. 그것은 일치하는 장소 에 아무 것도 하지 않는 완전히 별개의 패턴 구문입니다. 패턴 일치는 값이 아닌 장소 에서 작동 합니다 .
변수 바인딩에 가장 가까운 것은 ref _x 이지만, 그로 인해 충돌하는 차용을 피하기 위해 NLL이 필요할 수도 있습니다. 이것은 btw에서 작동합니다.

// The type `str` is the type of the place being matched. `x` has type `&str`.
let ref x: str = *"foo";
// Fully equivalent to this:
let x: &str = &*"foo";

@eddyb

당신은 내 요점을 이해하지 못했습니다. 내 가정은 Rust에서는 현재 코드에 크기가 조정되지 않은 rvalue가 전혀 나타날 수 없다는 것입니다. 그러나 let _:str = *"" 나타납니다. 그러한 가치는 한순간도 살지 못하지만, 통사적 수준에서는 살아 있습니다. 귀신같은거...

대신 귀하의 예는 기술적으로 완전히 합법적이며 요점이 아닙니다. str 는 크기가 지정되지 않았지만 &str 는 크기가 조정되었습니다.

그러나 let _:str = *""에 나타납니다. 그러한 가치는 한순간도 살지 못하지만, 통사적 수준에서는 살아 있습니다. 귀신같은거...

&*foo 와 같은 표현식에는 유사한 "고스트"가 있습니다. 먼저 foo 를 역참조한 다음 이동하지 않고 결과의 주소를 가져옵니다. 예를 들어 & { *foo } 와 같지 않습니다.

@earthengine @SimonSapin 크기가 rvalue ("값 표현식")가 존재하지 않습니다. lvalue("place 식")만 수행합니다. *"foo" 는 장소 이며 패턴 일치에는 값이 필요하지 않고 장소만 필요합니다.

"lvalue"와 "rvalue"라는 이름은 C에서도 유물이고 다소 오해의 소지가 있지만, let 의 RHS는 이름에도 불구하고 "lvalue"(장소 표현식)이기 때문에 Rust에서는 더욱 그렇습니다.
(할당 표현식은 Rust에서 C 이름과 규칙이 의미가 있는 유일한 곳입니다)

귀하의 예에서 let x = *"foo"; , 값은 x 에 바인딩하는 데 필요합니다.
마찬가지로 &*"foo" 는 장소 표현식을 생성한 다음 크기가 지정되지 않은 값을 생성할 필요 없이 차용하는 반면 {*"foo"} 는 항상 값 표현식이므로 크기가 지정되지 않은 유형을 허용하지 않습니다.

https://github.com/rust-lang/rust/pull/52420에서 나는 그것을 쳤다.

let Ok(b): Result<B, !> = ...;
b

더 이상 작동하지 않습니다. 의도적인가요?

AFAIK 예 -- 오류가 없는 패턴 스토리는 복잡하고 ! 자체와 별도의 기능 게이트가 있습니다. 또한 https://github.com/rust-lang/rfcs/pull/1872 및 https://github.com/rust-lang/rust/issues/48950을 참조하십시오.

@Ericson2314 특히 liballoc 에 추가해야 하는 기능은 exhaustive_patterns 입니다.

감사 해요!!

내부에 대한 흥미로운 대화:

• __문제:__ 쓸 수 없다
  rust fn make_iter() -> impl Iterator<Item=u32> { unimplemented!() // Error: ! does not implement Iterator }
! 가 임의의 관련 유형에 대해 Iterator 를 구현할 수 없기 때문
• __제안:__ <! as Trait>::Assoc 가 유형 추론 변수를 생성 하도록 합시다.
  
  
  
  • __참고:__ fn foo<T:Trait>() -> (T::Assoc, T::Assoc) 가 동일한 유형의 두 개를 생성하도록 보장 하려면 유형 시스템에 대한 확장 이 필요합니다.
  
  
• __반대예:__ typemap 상자가 불건전해집니다.

그렇게 할거면 왜 치료하지 마! 자신을 추론 변수로?

항목 유형을 명확하게 하기 위해 PhandomData 로 ! 주위에 래퍼를 만드십시오.

https://github.com/rust-lang/rust/issues/49593 이 수정되었습니다. 이것이 안정화의 이전 복귀의 이유였습니다. 이전 안정화 보고서는 여기에 있습니다 . 다시 시도해보자!

@rfcbot fcp 병합

rfcbot이 동일한 문제에서 둘 이상의 FCP를 지원할 수 있다고 생각합니다. 이번 안정화 라운드에 대한 새로운 문제를 열어 볼까요?

https://github.com/rust-lang/rust/pull/50121 안정화를 되돌릴 뿐만 아니라 폴백 시맨틱도 제공합니다. 이것이 우리가 다시 찾고 싶은 것입니까?

문제 설명에서 선택되지 않은 나머지 확인란은 다음과 같습니다.

! 대해 어떤 특성을 구현해야 합니까? 초기 PR #35162에는 Ord 및 기타 몇 가지가 포함됩니다. 이것은 아마도 T-libs 문제일 것이므로 해당 태그를 문제에 추가하고 있습니다.

나중에 impls를 추가할 수 있습니다. 그렇죠? 아니면 차단기인가요?

@SimonSapin 오픈 https://github.com/rust-lang/rust/issues/57012. ! 로의 폴백이 이 변경의 일부로 다시 활성화될 것으로 예상합니다. 예(안정화 문제에 대해 논의해 보겠습니다).

상호 참조: https://github.com/rust-lang/rust/issues/58184

분명히 기능 게이트 뒤에 입력하지 않는 버그/구멍이 있으며 Stable에서 참조할 수 있습니다. https://github.com/rust-lang/rust/issues/33417#issuecomment -467053097

편집: https://github.com/rust-lang/rust/issues/58733을 제출했습니다

위에 링크된 코드 ​​예제에서 유형 사용 추가:

trait MyTrait {
    type Output;
}

impl<T> MyTrait for fn() -> T {
    type Output = T;
}

type Void = <fn() -> ! as MyTrait>::Output;

fn main() {
    let _a: Void;
}

이것은 https://github.com/rust-lang/rust/pull/35162 에서 첫 번째라고 생각하는 Rust 1.12.0에서 컴파일됩니다

error: the trait bound `fn() -> !: MyTrait` is not satisfied [--explain E0277]
  --> a.rs:12:13
   |>
12 |>     let _a: Void;
   |>             ^^^^
help: the following implementations were found:
help:   <fn() -> T as MyTrait>

error: aborting due to previous error

이 상태는 어떤가요?

내가 아는 한 상태는 https://github.com/rust-lang/rust/issues/57012#issuecomment -467889706에 요약된 이후 크게 변경되지 않았습니다.

이 상태는 어떤가요?

@hosunrise : 현재 https://github.com/rust-lang/rust/issues/67225 에서 차단되었습니다.

여기에서 벗어날 수 있지만 Lint 토론(https://github.com/rust-lang/rust/issues/66173)에서 언급한 특정 문제는 모든 열거형에 ! 분기가 있으면 둘 다 해결할 수 있는 것처럼 보입니다. 타입 시스템?

https://github.com/rust-lang/rust/issues/67225 의 OP에 언급된 문제에는 적용되지 않으며 여전히 문제입니다.

여기에서 벗어날 수 있지만 모든 열거형에 유형 시스템에 ! 분기가 있으면 Lint 토론(#66173)에서 언급한 특정 문제가 모두 해결 가능한 것처럼 보입니까?

사실, 모든 열거형은 절대 발생할 수 없는 변종이 무한히 많기 때문에 위협을 받을 수 있으며, 따라서 모두 언급할 가치가 없습니다.