이것은 #25609에 의해 닫혀 있습니까?

@Munksgaard 그것은 단지 컴파일러 AFAIK에 대한 지원을 추가합니다. stdlib에는 const fn 로 변경하고 파손 여부를 테스트해야 하는 많은 기능이 있습니다. 진행 상황이 어떤지 모르겠습니다.

이것을 std::ptr::null() 및 null_mut() 에 구현하여 0usize as *mut _ 에 의존하지 않고 static mut *MyTypeWithDrop 를 초기화하는 데 사용할 수 있기를 바랍니다.

편집: 주제에서 벗어났기 때문에 제거됨

분명히 하자면, 여기서 질문은 주로 기능의 유용성에 관한 것이 아니라 오히려 그것을 공식화하는 가장 좋은 방법(또는 그것을 공식화하기 위한 최상의 프레임워크)에 관한 것입니다. RFC 토론을 참조하십시오.

이것은 이제 최종 안정화를 위한 추적 문제입니다.

https://github.com/rust-lang/rust/issues/29107 이 폐쇄되었습니다.

"패턴과의 통합" 또는 표준 라이브러리에 대한 변경 사항이 이를 차단해야 한다는 데 동의하지 않습니다. 이것은 이러한 변경 없이도 매우 유용하며 이러한 변경은 나중에 수행할 수 있습니다. 특히, 곧 내 코드에서 const fn 를 사용하기 시작하고 싶습니다.

따라서 이에 대한 안정화 상태를 재평가할 수 있는가?

현재 제한된 형태의 const fn 이더라도 유용한 기능이 될 것이라는 데 의심의 여지가 없지만, 이 경로를 더 이상 진행하기 전에 내가 정말 원하는 것은 " const fn 접근 방식"을 사용하여 선호하는 최종 게임에 대해 생각하고 설명합니다. 가장 분명한 방식으로 유용해 보이는 기능을 계속해서 추가하면 결국 C++의 constexpr 디자인 전체를 거의 복사하게 될 것 같습니다. 그게 우리가 편한 일입니까? 우리가 예라고 말하더라도, 나는 피할 수 없게 될 때까지 저항이 가장 적은 길로 시간이 지남에 따라 작은 단계로 후퇴하는 대신 맑은 눈으로 그 길을 선택하는 것이 훨씬 낫습니다.

(안전한 Rust 코드의 의미를 완전히 정의할 수 있어야 한다는 점을 감안할 때 unsafe 에 (전이적으로) 의존하지 않는 모든 함수는 결국 const 로 표시될 수 있어야 합니다. unsafe 가 구현 세부 사항이어야 한다는 점을 감안할 때 사람들이 어떻게든 그 제한을 완화하도록 밀어붙일 것입니다. 차라리 해외에서 더 응집력 있고 유능하며 스테이징 및 유형 수준 계산을 위한 잘 통합된 스토리)

@glaebhoerl

나는 현재의 제한된 형태의 const fn이 유용한 기능이 될 것이라고 의심하지 않습니다. 그들이 선호하는 최종 게임에 대해 생각하고 명확하게 설명하십시오... 우리가 결국 C++의 constexpr 디자인 전체를 거의 복사하게 될 가능성이 매우 높아 보입니다.

개인적으로 원하는 것은 무엇보다도 우리가 그것을 구현하는 방법과 언어의 어느 부분을 다룰 것인지에 대해 상당히 명확한 견해를 갖고 있다는 것입니다. 즉, 이것은 내 생각에 정수에 대한 관련 상수 또는 제네릭 지원과 매우 밀접하게 관련되어 있습니다.

@eddyb 와 저는 최근에 매우 광범위한 코드를 지속적으로 평가할 수 있는 방식에 대해 스케치를 했습니다. 기본적으로 모든 상수를 MIR로 낮추고 해석(경우에 따라
추상 해석, 아직 평가할 수 없는 제네릭이 있는 경우 가장 흥미로운 부분입니다.

그러나 "내장 언어"의 매우 많은 부분을 지원하는 것이 상당히 쉬운 것처럼 보이지만 실제로 실제 코드는 메모리 할당을 매우 빠르게 수행해야 하는 필요성에 부딪칩니다. 즉, Vec 또는 다른 컨테이너를 사용하려고 합니다. 그리고 여기에서 이 전체 해석 계획이 내 마음에 더 복잡해지기 시작합니다.

즉, @glaebhoerl , 귀하가 선호하는 대안적 최종 게임에 대해 분명히 말씀해 주셨으면 합니다. 나는 당신이 const fn RFC에서 그런 생각을 스케치했다고 생각하지만, 나는 그것을 다시, 그리고 이 맥락에서 듣는 것이 좋을 것이라고 생각합니다. :)

할당의 문제는 런타임으로 탈출하는 것입니다.
컴파일 타임/런타임 장벽을 넘는 것을 어떻게든 허용하지 않을 수 있다면 const fn 로 liballoc 가 작동할 수 있다고 생각합니다.
해석된 스택에서 바이트 주소 지정이 가능한 값을 처리하는 것보다 이러한 종류의 할당을 관리하는 것이 더 어렵지 않습니다.

또는 해당 장벽을 통과해야 할 때마다 값을 할당하고 채우는 런타임 코드를 생성할 수 있지만 어떤 종류의 사용 사례가 있는지 잘 모르겠습니다.

완전한 constexpr 와 같은 평가가 있더라도 const fn 는 _여전히_ 순수합니다. 'static 데이터에 대해 두 번 실행하면 똑같은 결과가 나오고 부작용.

@nikomatsakis 내가 하나 있었다면 나는 그것을 언급했을 것입니다. :) 나는 주로 알려진 미지의 것을 봅니다. 제네릭 시스템의 일부로 const 가 있는 모든 것은 물론 내가 C++ 디자인으로 이해한 것의 일부였습니다. const s 및 const 일반 매개변수를 연결하는 한, 우리는 이미 const 가 해당 유형의 일부로 포함된 고정 크기 배열이 있고 추상화하고 싶습니다. 더 일반적인 방법이 아닌 훨씬 더 나은 방법이 있다면 놀랄 것입니다. const fn 부분이 더 분리되고 가변적입니다. 더 나아가 제네릭에서 const impl s 및 const Trait 경계와 같은 것을 갖는 것을 상상하기 쉽지만, 저는 _확신_ 이런 종류의 일반적인 것에 대한 선행 기술이 있으며 이미 상황을 파악했습니다. 그리고 우리는 그것을 찾으려고 노력해야 합니다.

Rust 언어의 주요 사용 사례 중에서 커널과 같이 주로 저수준 제어를 필요로 하는 것들은 이미 충분히 잘 서비스된 것처럼 보이지만 Rust가 많은 잠재력을 가질 수 있는 또 다른 영역은 주로 고성능이 필요한 것들입니다. 단계적 계산( const fn 이 이미 매우 제한된 사례임)을 위한 공간의 강력한 지원(어떤 형태로든)은 게임 체인저가 될 수 있는 것처럼 보입니다. (지난 몇 주 동안 Rust에서 더 나은 스테이징 기능을 갖춘 언어로 전환하기로 결정한 사람들의 두 개의 개별 트윗 을 보았습니다.) 기존 솔루션이 "우리와 가까운" 언어로 된 것인지 확실하지 않습니다. C++의 constexpr , D의 ad-hoc CTFE, 우리의 절차적 매크로 -- 이런 종류의 일에 충분히 영감을 주고 강력하고/완벽하게 느껴집니다. (절차적 매크로는 있으면 좋은 것 같지만 성능 지향적인 코드 생성보다는 추상화와 DSL에 더 많이 사용됩니다.)

영감을 주고 충분히 좋은 것에 관해서는... 저는 아직 그것을 보지 못했고, 정확히 어디를 봐야 할지를 알 만큼 전체 공간에 익숙하지 않습니다. 물론 위의 내용에 따라 우리는 Julia와 Terra가 여러 면에서 Rust와 완전히 다른 언어처럼 보일지라도 최소한 한 눈에 보기를 원할 수 있습니다. 나는 Oleg Kiselyov가 이 분야에서 많은 흥미로운 일 을 했다는 것을 알고 있습니다. 스칼라를 위한 Lancet 및 Lightweight Modular Staging 에 대한 Tiark Rompf의 작업은 확실히 볼 가치가 있는 것 같습니다. @kmcallister 가 종속적으로 유형이 지정된 Rust가 어떻게 생겼는지에 대한 프레젠테이션을 본 기억이 있습니다 const 그 유형 자체는 일종의 스테이징입니다(컴파일과 런타임 사이의 위상 분리가 스테이지와 매우 유사하다는 점을 고려하면 자연스럽습니다)... 여러 방향에서 흥미로운 잠재적 연결이 많기 때문에 놓친 것처럼 느껴질 것입니다. 우리에게 발생하는 첫 번째 솔루션에 전념한다면 기회입니다. :)

(이것은 단지 브레인 덤프였으며 나는 많은 것을 거의 완벽하게 특성화하지 못했습니다.)

그러나 "내장 언어"의 매우 많은 부분을 지원하는 것이 상당히 쉬운 것처럼 보이지만 실제로 실제 코드는 메모리 할당을 매우 빠르게 수행해야 하는 필요성에 부딪칩니다. 즉, Vec 또는 다른 컨테이너를 사용하려고 합니다. 그리고 여기에서 이 전체 해석 계획이 내 마음에 더 복잡해지기 시작합니다.

나는 "실제 코드"의 특성화에 동의하지 않습니다. 힙 메모리 할당의 필요성을 줄이는 데 도움이 되기 때문에 Rust에 큰 관심이 있다고 생각합니다. 특히 내 코드는 가능할 때마다 힙 할당을 피하기 위해 구체적인 노력을 기울입니다.

그보다 더 많은 일을 할 수 있다면 _좋지만_ 컴파일러 강제 불변으로 중요하지 않은 유형의 정적 인스턴스를 구성할 수 있는 것은 필수적입니다. C++ constexpr 접근 방식은 매우 제한적이지만 내 사용 사례에 필요한 것 이상입니다. 매개 변수 x 를 사용하여 T 유형의 인스턴스를 생성할 수 있는 함수를 제공해야 합니다. x , y , z x , y , z 가 유효함을 보장하는 z (예: x < y && z > 0 ), 시작 시 실행되는 초기화 코드를 사용하지 않고 결과가 static 변수가 될 수 있습니다.

@briansmith FWIW 동일한 사용 사례를 해결할 기회가 있는 또 다른 접근 방식은 매크로에 개인 정보 보호 기능이 있는 경우입니다.

@briansmith FWIW 동일한 사용 사례를 해결할 수 있는 또 다른 접근 방식은 매크로에 개인 정보 보호 기능이 있는 경우입니다.

절차적 매크로를 사용하면 컴파일 타임에 x < y && z > 0 를 평가할 수 있습니다. 그러나 절차적 매크로가 안정적인 Rust에서 사용될 수 있기까지는 아주 많은 달이 걸릴 것 같습니다. const fn 는 내가 사물의 상태를 이해하는 한 안정적인 Rust _now_에 사용할 수 있기 때문에 흥미롭습니다.

@glaebhoerl 나는 엄격한 위생을 위해 숨을 참지 않을 것입니다. 우리가 탈출 메커니즘을 가질 가능성이 매우 높기 때문에(실제 LISP와 마찬가지로) 어떤 종류의 안전 목적으로도 원하지 않을 수 있습니다.

@glaebhoerl https://anydsl.github.io/도 있으며, 심지어 다음을 사용합니다.
Rust와 유사한 구문 ;) 기본적으로 단계적 계산을 목표로 하고 있습니다.
특정 부분 평가.

2016년 1월 16일 토요일 오후 6시 29분, Eduard-Mihai Burtescu <
[email protected]>은 다음과 같이 썼습니다.

@glaebhoerl https://github.com/glaebhoerl 나는 숨을 참지 않을 것입니다
엄격한 위생, 탈출 장치가 있을 가능성이 큽니다.
(진짜 LISP처럼), 그래서 당신은 어떤 종류의 안전을 위해 그것을 원하지 않을 수도 있습니다
목적.

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

29525는 안정화 전에 수정되어야 합니다.

안전한 Rust 코드의 의미를 완전히 정의할 수 있어야 한다는 점을 감안할 때, 결국 unsafe 에 (전이적으로) 의존하지 않는 모든 함수는 const 로 표시될 수 있어야 합니다. . 그리고 unsafe 가 구현 세부 사항이어야 한다는 점을 감안할 때 사람들이 어떻게든 그 제한을 완화하기 위해 추진할 것입니다.

생각해 보세요: Rust의 메모리 모델 을 공식적으로 정의한다면 unsafe 코드도 추상적으로/기호적으로 해석하여 컴파일 타임에 잠재적으로 안전하고 현명하게 평가될 수 있습니다. 즉, 원시 포인터를 사용하면 ' t 런타임 시와 같은 직접 메모리 액세스로 전환하는 대신 할당된 주소의 해시맵 조회와 해당 유형 및 값 또는 이와 유사한 것으로 모든 단계에서 유효성을 검사하는 것과 같은 것입니다. 동작이 정의되지 않은 실행은 rustc 의 보안 취약점 대신 _엄격히_ 컴파일러가 보고한 오류입니다. (이것은 컴파일 타임에 isize 및 usize 를 기호적으로 또는 플랫폼 종속적인 방식으로 처리하는 상황과 연결될 수도 있습니다.)

const fn 와 관련하여 그것이 우리를 어디로 떠나는지 잘 모르겠습니다. 한편으로는 Box , Vec , Rc , unsafe 를 사용하는 모든 코드를 컴파일 타임에 사용할 수 있는 훨씬 더 유용한 코드를 열 수 있습니다. 성능 최적화를 위한 const fn 가 될 수 있는 것"에 대한 경계는 이제 본질적으로 _FFI를 포함하지 않는 모든 것_으로 바깥쪽으로 이동됩니다. 따라서 우리가 const 이라는 위장 하에 유형 시스템에서 _실제로_ 추적할 것은 FFI에 (전이적으로) 의존하는 것과 그렇지 않은 것입니다. 그리고 무언가가 FFI를 사용하는지 여부는 _여전히_ 사람들이 정당하게 내부 구현 세부 사항으로 간주하는 것이며, 이 제한( unsafe 과 달리)은 _정말_ 해제할 가능성이 없어 보입니다. 그리고 이 시나리오에서는 const 자격이 없는 것보다 훨씬 더 많은 fn 가 있을 것입니다.

따라서 여전히 임의의 구현 노출 제한을 중심으로 회전하는 const 이 있으며 거의 ​​모든 곳에서 const 를 작성해야 합니다. 그것도 그다지 매력적으로 들리지 않는군요...

즉, 원시 포인터의 사용은 런타임과 같은 직접적인 메모리 액세스로 바뀌지 않고 할당된 주소의 해시맵 조회와 같은 것입니다.

@glaebhoerl 글쎄, 그것은 내가 설명한 모델 과 @tsion 의 miri 가 구현하는 모델입니다.

일관성을 위해 _필요한_ 순수성 때문에 FFI 구분이 매우 중요하다고 생각합니다.
Rust const fn 에는 unsafePerformIO 가 있기 때문에 GHC 를 사용할 수도 _없습니다_.

나는 const 키워드를 너무 좋아하지 않기 때문에 const fn foo<T: const Trait> const fn foo<T: Trait> 를 사용하는 것이 좋습니다( const impl Trait for T 필요).

Sized 와 마찬가지로 기본값이 잘못되었을 수 있지만 현실적으로 작동할 수 있는 다른 제안은 본 적이 없습니다.

@eddyb https://internals.rust-lang.org/t/mir-constant-evaluation/3143/31 (댓글 31이 아닌 11)에 연결하려는 것 같습니다.

@tsion 고정, 감사합니다!

내가 완전히 벗어났다면 이것을 무시하십시오.

이 RFC에서 볼 수 있는 문제는 사용자로서 가능한 한 많은 함수 const fn 를 표시해야 한다는 것입니다. 왜냐하면 이것이 아마도 모범 사례일 것이기 때문입니다. 같은 일이 현재 C++에서 contexpr을 사용하여 일어나고 있습니다. 나는 이것이 단지 불필요한 장황함이라고 생각합니다.

D에는 const fn 가 없지만 컴파일 시간에 모든 함수를 호출할 수 있습니다(일부 예외 있음).

예를 들어

// Standalone example.
struct Point { x: i32, y: i32 }

impl Point {
    fn new(x: i32, y: i32) -> Point {
        Point { x: x, y: y }
    }

    fn add(self, other: Point) -> Point {
        Point::new(self.x + other.x, self.y + other.y)
    }
}

const ORIGIN: Point = Point::new(0, 0); // works because 0, 0 are both known at compile time 
const ORIGIN2: Point = Point::new(0, 0); // ditto

const ANOTHER: Point = ORIGIN.add(ORIGIN2); // works because ORIGIN and ORIGIN2 are both const.
{
    let x: i32 = 42;
    let y: i32 = 24;
    const SOME_POINT: Point = Point::new(x, y); // Error: x and y are not known at compile time
}
{
    const x: i32 = 42;
    const y: i32 = 24;
    const SOME_POINT: Point = Point::new(x, y); // Works x and y are both known at compile time.
}

참고로 저는 실제로 Rust 사용자가 아니며 RFC를 몇 분 전에 읽었기 때문에 제가 뭔가를 잘못 이해했을 수도 있습니다.

@MaikKlein RFC 토론 에서 CTFE에 대한 많은 토론이 있었습니다.

여기에 차단기를 설명하는 최근 댓글이 없으며 작업이 그다지 명확하지 않습니다. 상태가 어떻습니까? 이것을 결승선을 가로질러 어떻게 이동할 수 있습니까?

이것은 로켓에서 사용됩니다: https://github.com/SergioBenitez/Rocket/issues/19#issuecomment -269052006

https://github.com/rust-lang/rust/issues/29646#issuecomment -271759986을 참조하세요. 또한 miri가 "전역적 부작용"에 대한 한계를 넘었기 때문에 명시성에 대한 우리의 입장을 재고해야 합니다( @solson 및 @nikomatsakis 는 IRC에서 이에 대해 이야기하고 있었습니다).

이 RFC에서 볼 수 있는 문제는 사용자로서 가능한 한 많은 기능 const fn을 표시해야 한다는 것입니다. 왜냐하면 그것이 아마도 모범 사례일 것이기 때문입니다.

임의의 함수를 호출 가능하게 만들 수는 있지만 해당 함수가 C 코드 또는 정적에 액세스하면 계산할 수 없습니다. 해결책으로 const fn이 될 수 있는 공용 기능에 대해 경고하는 린트를 제안합니다.

나는 린트에 대해 동의합니다. 기존 내장 린트 missing_docs , missing_debug_implementations 및 missing_copy_implementations 와 유사합니다.

기본적으로 보푸라기를 켜는 데는 일종의 문제가 있지만... const 가 되는 것을 명시적으로 원하지 않는 함수에 대해 경고합니다. 예를 들어 나중에 함수를 다음과 같이 변경할 계획이기 때문입니다. const 일 수 없고 인터페이스를 const 로 커밋하고 싶지 않습니다( const 제거는 주요 변경 사항입니다).

#[allow(missing_const)] fn foo() {} 이런 경우에 효과가 있을 것 같습니까?

@eddyb @nikomatsakis " const 을 제거하는 것은 주요 변경 사항입니다." 요점은 fn이 fn 이 _remain_ const 한다는 다운스트림에 대한 약속이기 때문에 결국 키워드를 갖고 싶어한다는 것을 암시합니다.

std 및 기타 라이브러리를 통해 얼마나 많은 const 가 뿌려져야 하는지는 수치스러운 일이지만 공개적으로만 요구되지 않는 한 어떻게 피할 수 있는지 모르겠습니다. 직면하는 항목, 그리고 그것은 혼란스러운 규칙처럼 보입니다.

공개 항목에만 필요하고 혼란스러운 규칙처럼 보이지 않는 한.

나는 이것을 좋아한다... 나는 그것이 혼란스러울 것이라고 생각하지 않는다. const fn 에 의해 호출되는 함수를 const가 아닌 함수로 만들 수 없기 때문에 공개 인터페이스가 보호됩니다.

기술적으로 notconst 함수에 주석을 추가하는 것이 더 나을 것입니다. 다른 방법보다 const fn 가 더 많을 것으로 예상하기 때문입니다.

notconst 는 또한 Rust의 디자인 철학과 더 일치합니다. (예: " mut , const " 아님)

공개 항목에만 필요하고 혼란스러운 규칙처럼 보이지 않는 한.

나는 이것을 좋아한다... 나는 그것이 혼란스러울 것이라고 생각하지 않는다.

나는이 아이디어에 플립 플롭입니다. 장점이 있지만(공개 인터페이스 결정을 내릴 때 const fn 고려 ) 혼란스러울 수 있는 다른 방법을 생각했습니다.

const fn 에 의해 호출되는 함수를 const가 아닌 함수로 만들 수 없기 때문에 공개 인터페이스가 보호됩니다.

이것은 사실이며 불행히도 라이브러리 작성자가 공개 함수 const 를 표시할 때 암시적으로 해당 함수 const 에 의해 전이적으로 호출되는 모든 함수도 표시하고 있으며 기회가 있습니다. 원하지 않는 기능을 의도하지 않게 표시하고 있으므로 향후 비 const 기능을 사용하여 이러한 내부 기능을 다시 작성하는 것을 방지합니다.

다른 방법보다 const fn 가 더 많을 것으로 예상합니다.

나는 잠시 동안 이런 생각을 했지만 순수한 Rust 라이브러리 크레이트에만 해당될 것입니다. FFI 기반 fns를 const로 만드는 것은 가능하지 않을 것입니다. (그것들이 단지 전이적으로 FFI 기반이더라도, 이는 많은 일입니다), 따라서 const fn 의 순전한 금액은 그리 나쁘지 않을 수 있습니다. 당신과 내가 생각한 대로.

내 현재 결론: 명시적이지 않은 const fn 는 문제가 있는 것 같습니다. 키워드를 많이 쓰는 것을 피하는 좋은 방법이 없을 수도 있습니다.

또한 기록을 위해 notconst 는 주요 변경 사항입니다.

@solson 아주 좋은 지적입니다.

키워드를 특성 방법과 함께 사용하려고 하면 키워드가 더 많아진다는 점을 염두에 두십시오. 특성 정의로 제한하는 것은 충분히 유용하지 않으며 impls에 주석을 추가하면 불완전한 "const fn parametrim" 규칙이 생성됩니다.

이 절충안은 처음에 const fn 를 채택했을 때 꽤 철저하게 논의된 것 같습니다. @solson 님 의 분석도 맞다고 생각합니다. 변경된 유일한 것은 아마도 constable fns의 비율이 더 커졌다는 것뿐이지만 여기서 근본적인 절충안을 변경할 만큼 충분히 생각하지 않습니다. const fn 를 공용 인터페이스 등에 점차적으로 추가해야 하는 것은 성가신 일이지만 이것이 인생입니다.

@nikomatsakis 나를 괴롭히는 것은 다음 두 가지 사실의 조합입니다.

• 모든 것을 미리 확인할 수는 없습니다. unsafe 코드는 "동적으로 비 const"일 수 있습니다.
• 제네릭과 특성 임플에 대해 무엇을 하든 "올바른" 것과 유연한 것 사이의 절충점이 될 것입니다.

"글로벌 부작용"이 코드가 const fn 가 되지 않도록 하는 주요 원인이라는 점을 감안할 때 이것이 Rust가 가지고 있던 제거된 "효과 시스템"이 아닙니까?
"효과 안정성"에 대해 이야기해야 하지 않습니까? 일부 라이브러리가 IMO를 패닉하지 않는다고 가정하는 코드와 유사해 보입니다.

@eddyb 절대적으로 const 는 효과 시스템이고 예, 가능한 한 피하고 싶게 만드는 모든 단점이 있습니다... 추가하는 고통을 견디려면 그럴듯합니다. 효과 시스템에서 다른 종류의 효과로 확장할 수 있는 일부 구문을 고려할 수 있습니다. 예를 들어 우리는 unsafe 와 비슷한 가격을 지불하고 있습니다(효과도 있음). 하지만 그것들을 통합하는 것에 대해 생각하는 것이 이치에 맞는지 잘 모르겠습니다.

위반이 동적으로 발생할 수 있다는 사실이 이 옵트인을 선택해야 하는 훨씬 더 많은 이유처럼 보입니다.

이것은 어떤가요:

일반적으로 const fn s는 생성자( new ) 또는 절대적으로 필요한 경우에만 사용해야 한다고 생각합니다.

그러나 때때로 상수를 편리하게 생성하기 위해 다른 방법을 사용하고 싶을 수도 있습니다. constness를 기본값으로 설정 하지만 정의하는 모듈에 대해서만 이 문제를 많은 경우에 해결할 수 있다고 생각합니다. 이렇게 하면 const 로 명시적으로 보장되지 않는 한 종속 항목은 constness를 가정할 수 없으며 모든 것을 const 로 만들지 않고 함수로 상수를 생성할 수 있는 편리함을 유지합니다.

@torkleyy 내보내지 않은 도우미가 있으면 이미 할 수 있습니다.

개인 도우미 함수는 가능한 경우 암시적으로 const 해서는 안 된다는 강력한 주장이 없습니다. @solson 은 도우미 함수에 대해서도 const 를 명시적으로 만들면 프로그래머가 일시 중지하고 해당 함수를 const 로 커밋할지 여부를 고려해야 한다고 말한 것 같습니다. 그러나 프로그래머가 이미 공용 기능에 대해 생각해야 한다면 그것으로 충분하지 않습니까? 여기저기에 const 를 쓰지 않아도 되는 것 아닌가요?

IRC 에서 @eddyb 는 선언과 본문의 세부 사항을 파악하기 전에 const fns에 대한 호출 을 안정화할 수 있도록 이 기능 게이트를 분할할 것을 제안했습니다. 좋은 생각 같나요?

@durka 컴파일러 내부에 대해 잘 모르는 Rust 사용자인 저에게는 정말 좋은 것 같습니다.

이해가 부족해서 죄송합니다. 하지만 선언을 안정화하지 않고 const 함수에 대한 호출을 안정화한다는 것은 무엇을 의미합니까?

컴파일러가 어떤 수단을 통해 상수와 상수가 아닌 것을 어떻게든 알 수 있지만 해당 부분은 당분간 토론/구현을 위해 열어 둡니다.

컴파일러가 나중에 상수가 무엇인지에 대해 마음을 바꿀 수 있다면 호출을 어떻게 안정화할 수 있습니까?

@nixpulvis 일부 const fn 는 이미 표준 라이브러리에 존재합니다(예 UnsafeCell::new ). 이 제안은 예를 들어 static 항목의 이니셜라이저와 같이 일정한 컨텍스트에서 이러한 함수를 호출할 수 있도록 합니다.

@nixpulvis 내 말은 안정적인 Rust 코드에 정의된 일반 함수가 아니라 상수 컨텍스트에서 불안정한 사용 코드(예: 표준 라이브러리)에 의해 정의된 const fn 함수에 대한 호출을 의미했습니다.

cc @rust-lang/lang on https://github.com/rust-lang/rust/issues/24111#issuecomment -310245900

나는 더 빨리 일어날 수 있다면 먼저 const fn 에 대한 호출을 안정화하는 것에 찬성하지만 모든 const fn 기능을 안정화하는 것을 차단하는 것이 무엇인지 명확하지 않습니다. 오늘날 남아 있는 우려 사항은 무엇입니까? 이를 해결하기 위한 경로는 무엇입니까?

@SimonSapin 오늘날 확장성이 좋은 const fn 를 선언하기 위한 디자인이 명확하지 않고 이들과 특성 사이의 상호 작용 및 얼마나 많은 유연성이 있어야 하는지 확신할 수 없습니다.

나는 const fn의 사용을 안정화하려는 경향이 있다고 생각합니다. 이것은 인체 공학적이고 표현력이 뛰어나며 "일반 코드를 작성"하는 것보다 컴파일 시간 상수 평가를 처리하는 더 좋은 방법을 여전히 상상할 수 없습니다.

const fn의 사용을 안정화합니다.

이것은 또한 표준 라이브러리의 일부 기능을 const 로 안정화합니다. 라이브러리 팀은 최소한 감사를 수행해야 합니다.

@petrochenkov당 감사할 기능 목록과 함께 호출을 안정화하기 위해 PR https://github.com/rust-lang/rust/issues/43017 을 제출했습니다.

특정 특성/impl 상황에서 이것이 어떻게 사용될 수 있는지에 대한 질문/의견이 있습니다. Zero 특성을 가진 수학 라이브러리가 있다고 가정해 보겠습니다.

pub trait Zero {
    fn zero () -> Self;
}

이 특성은 $#$ Vec $#$ 에 의해 뒷받침되는 일부 BigInt 유형에 의해 암시되는 것을 방지하기 때문에 zero 메소드가 const 일 필요가 없습니다. 그러나 기계 스칼라 및 기타 단순 유형의 경우 메소드 가 const 이면 훨씬 더 실용적입니다.

impl Zero for i32 {
    const fn zero () -> i32 { 0 } // const
}

impl Zero for BigInt {
    fn zero () -> BigInt { ... } // not const
}

특성은 메소드가 const 일 필요 는 없지만 const 는 구현에 제한을 추가하고 무시하지 않기 때문에 여전히 허용되어야 합니다. 이것은 일부 유형에 대해 동일한 기능의 일반 버전과 const 버전을 갖는 것을 방지합니다. 궁금한 점은 이 문제가 이미 해결되었습니까?

특성의 다른 구현이 다르게 동작하기를 원하는 이유는 무엇입니까? 일반 컨텍스트에서는 사용할 수 없습니다. const fn을 사용하여 스칼라에 로컬 impl을 만들 수 있습니다.

@Daggerbot 이것이 내가 특성에서 const fn 에 대해 앞으로 볼 수 있는 유일한 방법입니다. 특성을 갖는 것은 모든 impls가 const fn 여야 한다는 것을 요구하는 것이 효과적으로 " const impl s"를 갖는 것보다 훨씬 덜 일반적입니다. .

@jethrogb constness 가 impl의 속성이 되어야 하지만 가능합니다.
내가 염두에 두고 있는 것은 예를 들어 T: Zero 바운드가 있는 일반 const fn 에는 $#$7$#에 대한 impl 의 Zero 가 필요하다는 것입니다 T s 호출이 상수 컨텍스트 자체(예: 다른 const fn )에서 올 때 const fn 메서드만 포함하기 위해 호출됩니다.

완벽하지는 않지만 더 나은 대안이 제시되지 않았습니다. 가장 가까운 IMO는 "컴파일 타임에 불가능한 것이 시도되면 호출 스택에서 깊은 오류와 호출을 허용"하는 것만큼 나쁘지는 않습니다. 첫 인상에 보일 수 있습니다 - 그것에 대한 대부분의 우려는 이전 버전과의 호환성과 관련이 있습니다. 예를 들어 const fn 함수를 표시하면 사실이 기록되고 컴파일 타임에 유효하지 않은 작업을 수행하는 것은 그렇지 않도록 해야 합니다. const fn .

이렇게 하면 문제가 해결되지 않습니까?

pub trait Zero {
    fn zero() -> Self;
}

pub trait ConstZero: Zero {
    const fn zero() -> Self;
}

impl<T: ConstZero> Zero for T {
    fn zero() -> Self {
        <Self as ConstZero>::zero()
    }
}

상용구는 매크로로 줄일 수 있습니다.

거의 똑같은 일을 하는 두 개의 개별 특성( Zero 및 ConstZero )이 있다는 사소한 불편을 제외하고는 포괄적인 구현을 사용할 때 잠재적인 문제가 하나 있습니다.

// Blanket impl
impl<T: ConstZero> Zero for T {
    fn zero () -> Self { T::const_zero() }
}

pub struct Vector2<T> {
    pub x: T,
    pub y: T,
}

impl<T: ConstZero> ConstZero for Vector2<T> {
    const fn const_zero () -> Vector2<T> {
        Vector2 { x: T::const_zero(), y: T::const_zero() }
    }
}

// Error: This now conflicts with the blanket impl above because Vector2<T> implements ConstZero and therefore Zero.
impl<T: Zero> Zero for Vector2<T> {
    fn zero () -> Vector2<T> {
        Vector2 { x: T::zero(), y: T::zero() }
    }
}

블랭킷 impl을 제거하면 오류가 사라집니다. 대체로 이것은 언어에 최소한의 복잡성을 추가하기 때문에 컴파일러에서 구현하기 가장 쉬울 것입니다.

그러나 필요하지 않은 구현된 메서드에 const 를 추가할 수 있다면 완벽하지는 않지만 이러한 중복을 피할 수 있습니다.

impl<T: Zero> Zero for Vector2<T> {
    const fn zero () -> Vector2<T> {
        Vector2 { x: T::zero(), y: T::zero() }
    }
}

IIRC, C++에서는 constexpr 로 작업할 때 이와 같은 것을 허용합니다. 여기서 단점은 이 const 가 <T as Zero>::zero 도 const 인 경우에만 적용할 수 있다는 것입니다. 이것은 오류여야 합니까, 아니면 컴파일러가 적용할 수 없는 경우(예: C++) 이 const 를 무시해야 합니까?

이러한 예 중 어느 것도 문제를 완벽하게 해결하지 못하지만 더 나은 방법이 생각나지 않습니다.

편집: @andersk 의 제안은 첫 번째 예를 오류 없이 가능하게 만들 것입니다. 이것은 아마도 컴파일러 구현이 진행되는 한 최고의/가장 간단한 솔루션이 될 것입니다.

@Daggerbot 이것은 RFC 1210(전문화) 의 끝 부분에 제안된 "격자" 규칙의 사용 사례처럼 들립니다. 당신이 쓰는 경우

impl<T: ConstZero> Zero for T {…}  // 1
impl<T: ConstZero> ConstZero for Vector2<T> {…}  // 2
impl<T: Zero> Zero for Vector2<T> {…}  // 3
impl<T: ConstZero> Zero for Vector2<T> {…}  // 4

1은 3과 겹치지만 교차점은 정확히 4로 덮여 있으므로 격자 규칙에 따라 허용됩니다.

http://smallcultfollowing.com/babysteps/blog/2016/09/24/intersection-impls/도 참조하십시오.

그것은 우리가 피하고 싶은 엄청나게 복잡한 시스템입니다.

예, 격자 규칙이 필요합니다.

@eddyb 무엇이 복잡하다고 생각하십니까?

@Kixunil impl 를 const fn 로 "단순히" 표시하는 대신 표준 라이브러리의 거의 모든 단일 특성을 복제합니다.

우리는 여기서 벗어나고 있습니다. 현재 문제는 const fn 의 사용 안정화에 관한 것입니다. const fn 특성 메소드 또는 const impl Trait for Foo 허용은 서로 및 허용되는 RFC에 직교합니다.

@oli-obk 이것은 새로운 RFC가 아니라 const fn 에 대한 추적 문제입니다.

방금 눈치채고 댓글 수정했습니다.

@eddyb 네, 하지만 컴파일러에서는 더 간단하고(특화를 빼지만 어쨌든 특화를 원할 것입니다) 사람들도 ConstTrait 로 묶을 수 있습니다.

어쨌든 나는 impls를 const로 표시하는 것에 반대하지 않습니다. 나는 또한 ConstTrait: Trait 자동 생성 컴파일러를 상상하고 있습니다.

@Kixunil 특히 전문화로 할 수 있다면 훨씬 간단하지 않습니다.
컴파일러는 ConstTrait: Trait 와 같은 것을 자동 생성할 필요도 없고 특성 시스템이 이것에 대해 알 필요도 없습니다. 구현을 통해 재귀하면 됩니다(구체적인 impl 또는 where bound) 트레잇 시스템이 제공하고 확인합니다.

const fns가 UnsafeCell 에 대한 액세스를 허용하지 않아야 하는지 궁금합니다. 아마도 진정한 const 동작을 허용해야 할 것입니다.

const fn dont_change_anything(&self) -> bool {
    let old = self.cell.get();
    self.cell.set(!old);
    old
}

지금까지 나는 set 가 const $ 이 아니라는 것을 보았습니다. 문제는 이것이 영원히 지속될 것인지 여부입니다. 다시 말해, unsafe 코드가 불변 데이터에 대해 동일한 const 함수를 실행할 때 현재와 언어/라이브러리의 모든 향후 릴리스에서 항상 동일한 결과를 반환할 것이라고 믿을 수 있습니까?

const fn 는 불변을 의미하는 것이 아니라 컴파일 타임에 호출될 수 있음을 의미합니다.

내가 참조. 어떻게든 가능하다면 unsafe 특성을 사용하지 않고 함수가 여러 번 호출될 때 항상 동일한 결과를 반환한다는 것을 어떻게든 보장할 수 있다면 대단히 감사하겠습니다.

@Kixunil 원하는 https://github.com/rust-lang/rfcs/issues/1631

@jethrogb 링크 주셔서 감사합니다!

mem::size_of 가 야간에 const fn 로 구현된다는 것을 알았습니다. mem::transmute 및 기타 사용자에게 이것이 가능합니까? Rust 내장 함수는 컴파일러 내부에서 작동하며 이를 허용하기 위해 적절한 변경을 수행할 만큼 충분히 익숙하지 않습니다. 그렇지 않으면 기꺼이 구현하겠습니다.

불행히도 값에 대한 작업은 마법처럼 일부를 생성하는 것보다 약간 어렵습니다. transmute 에는 미리가 필요합니다. miri를 컴파일러로 가져오기 위한 첫 번째 단계는 이미 진행 중입니다. #43628

그래서! *Cell::new , mem::{size,align}_of , ptr::null{,_mut} , Atomic*::new , Once::new 및 {integer}::{min,max}_value 를 안정화하는 데 관심이 있으십니까? 여기에 FCP를 추가하거나 개별 추적 문제를 생성해야 합니까?

네.

나는 이것에 대해 결정권을 가진 팀의 일원은 아니지만 내 개인적인 생각은 mem::{size,align}_of 를 제외한 이 모든 것들은 고무 스탬프의 움직임을 거치지 않고 지금 안정화 될 수있을 정도로 사소하다는 것입니다. FCP.

사용자로서 나는 가능한 한 빨리 const 표현식에서 mem::{size,align}_of 를 사용하고 싶지만 const fn s로 만들어졌을 때 insta-const-stable이 되는 것에 대한 @nikomatsakis 의 우려 표현을 읽었습니다. . 특정 우려 사항이 있는지 아니면 일반적인 주의 사항이 있는지는 모르겠지만 IIRC가 기능별 기능 게이트가 추가된 이유입니다. 이 두 가지에 대한 우려는 FCP를 공유할 수 있을 정도로 비슷할 것이라고 생각합니다. @rustbot 이 동일한 GitHub 스레드에서 별도의 FCP를 처리할 수 있는지 여부는 모르겠으므로 별도의 문제를 여는 것이 더 나을 것입니다.

@durka 이러한 모든 기능의 일관성을 안정화하기 위해 단일 추적 문제를 열 ​​수 있습니까? FCP가 올라오면 제안하겠습니다.

@aturon https://github.com/rust-lang/rust/issues/46038

alloc::Layout의 const fns에 대한 토론 에서 리드를 따르려면 다음을 수행하십시오.
const fn 에서 패닉을 허용하고 컴파일 오류로 처리할 수 있습니까? 이것은 상수 산술 표현식으로 지금 수행되는 것과 유사하지 않습니까?

예, 미리가 병합되면 아주 사소한 기능입니다.

const 가 되는 추가 std 기능을 요청하기에 적합한 곳입니까? 그렇다면 Duration:: { new , from_secs , from_millis } 는 모두 const 를 만드는 데 안전해야 합니다.

@remexre 그것을 가능하게 하는 가장 쉬운 방법은 아마도 PR을 만들고 거기에서 libs 팀 검토를 요청하는 것입니다.

https://github.com/rust-lang/rust/pull/47300으로 홍보했습니다. 또한 불안정한 생성자에 const 를 추가했습니다.

추가 std 함수를 const 선언하도록 허용하는 것에 대한 생각이 있습니까? 특히 mem::uninitialized 및 mem::zeroed ? 이 두 가지가 추가 const 기능에 적합한 후보라고 생각합니다. 내가 생각할 수 있는 유일한 단점은 Drop 를 구현하는 구조체 생성이 ptr::write 없이 생성되고 덮어쓰여지는 mem::uninitialized 의 동일한 단점입니다.

이것이 적절하게 들리면 PR도 첨부할 수 있습니다.

그 동기는 무엇입니까? 덮어쓸 수 없는 유효하지 않은 비트 패턴을 만드는 것은 쓸모없는 것처럼 보이지만(그들은 const에 있기 때문에), 아마도 나는 명백한 것을 간과하고 있을 것입니다.

mem::uninitialized 는 절대적으로 풋건으로, 부적절하게 조준하면 손을 통해 쏘기도 합니다. 진지하게, 나는 unsafe 로 표시되어 있음에도 불구하고 이 함수의 사용이 얼마나 믿을 수 없을 정도로 위험한지 과장할 수 없습니다.

이러한 추가 함수 const 를 선언하는 동기는 이러한 함수의 특성에서 비롯됩니다. mem::uninitialized<Vec<u32>> 를 호출하면 부작용 없이 매번 동일한 결과가 반환되기 때문입니다. 분명히 초기화하지 않은 채로 두면 이것은 끔찍한 일입니다. 따라서 unsafe 는 여전히 존재합니다.

그러나 사용 사례의 경우 일부 기능의 시작을 추적하는 전역 타이머를 고려하십시오. 내부 상태는 나중에 결정되지만 실행 시 생성되는 정적 전역 구조체로 표시할 방법이 필요합니다.

use std::time::Instant;

pub struct GlobalTimer {
    time: UnsafeCell<Instant>
}

impl TimeManager {
    pub const fn init() -> TimeManager {
        TimeManager {
            time: UnsafeCell::new(Instant::now())
        }
    }
}

이 코드는 Instant::now() 가 const 함수가 아니기 때문에 컴파일되지 않습니다. mem::uninitialized 가 const fn 인 경우 $ Instant::now() 를 mem::uninitialized::<Instant>()) 로 바꾸면 이 문제가 해결됩니다. 이상적으로는 프로그램이 실행을 시작하면 개발자가 이 구조를 초기화합니다. 그리고 이 코드는 관용적이지 않은 녹으로 간주되지만(전역 상태는 일반적으로 매우 나쁨) 전역 정적 구조가 유용한 많은 경우 중 하나일 뿐입니다.

이 게시물이 컴파일 타임에 실행되는 Rust 코드의 미래에 대한 좋은 토대를 제공한다고 생각합니다. 전역 컴파일 타임 정적 구조는 현재 녹이 없는 몇 가지 중요한 사용 사례(OS도 염두에 둡니다)가 있는 기능입니다. $ unsafe mem::uninitialized 및 mem::zeroed 와 같이 적절하다고 판단되는 라이브러리 함수에 const 를 천천히 추가하여 이 목표를 향한 작은 단계를 수행할 수 있습니다.

편집: TimeManager::init() 의 함수 서명에서 const 를 잊어버렸습니다.

흠, 그 코드 는 컴파일 되므로 여기서 정확한 동기를 놓치고 있습니다... 다음과 같은 코드를 작성할 수 있다면

const fn foo() -> Whatever {
    unsafe { 
        let mut it = mem::uninitialized();
        init_whatever(&mut it);
        it
    }
}

하지만 const fns는 현재 너무 제한적이어서 쓸 수도 없습니다...

이론적 근거에 감사하지만 const 는 pure 와 같지 않으며 일부 매력적인 사용 사례에 필요하지 않은 경우 이러한 기능의 사용을 권장하기 위해 아무 조치도 취하지 않아야 한다고 생각합니다. .

먼저 안정될 수 있는 더 낮은 매달린 과일이 있다고 생각합니다. 미리가 없으면 초기화되지 않고 0이 되는 내장 함수는 어쨌든 의미가 없습니다. 그래도 언젠가는 보고 싶습니다. 우리는 초기에 그것들을 안정화할 수도 있고, 중간 계산이 초기화되지 않을 수 있다 하더라도 모든 상수가 초기화된 결과를 생성하도록 요구할 수도 있습니다.

즉, 공용체 및 안전하지 않은 코드를 사용하면 어쨌든 초기화되지 않거나 0이 된 것을 에뮬레이트할 수 있으므로 비 const로 유지하는 것은 의미가 없습니다.

union 의 도움으로 이전 코드는 이제 . 완전 겁나 ㅋㅋㅋ

좋은 점들도 모두. 이러한 내장 함수는 사용 사례 목록에서 매우 낮지만 최종 const -ness에 여전히 적합한 후보입니다.

정말 놀랍습니다.

그래서... 정확히 mem::uninitialized를 구성하는 것을 옹호하는 이유는 다음과 같습니다.
Instant::now?에 반대합니다. :)

상수가 아닌 구조체에는 상수 이니셜라이저가 필요합니다.
내부는 실제입니다(참조: Mutex). 그러나 나는 이것을 말라키라고 생각하지 않는다.
더 쉽게 얻을 수있는 올바른 방법입니다!

2018년 1월 25일 목요일 오전 2시 21분, Stephen Fleischman <
[email protected]>은 다음과 같이 썼습니다.

공용체의 도움으로 이전 코드는 이제 컴파일됩니다.
https://play.rust-lang.org/?gist=be075cf12f63dee3b2e2b65a12a3c854&version=nightly .
완전 겁나 ㅋㅋㅋ

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

Instant::now 는 const일 수 없습니다. 그 함수는 무엇을 반환할까요? 편집의 시간?

누군가 이것을 안정화하기 위해 수행해야 할 작업을 요약할 수 있습니까? 어떤 결정에 도달해야 합니까? 이 모든 것을 안정화할지 여부?

패턴과의 통합(예: https://gist.github.com/d0ff1de8b6fc15ef1bb6)

이미 요점에 대해 언급했지만 현재 const fn 는 패턴에서 비교할 수 없으므로 안정화를 차단해서는 안 됩니다. 의미가 있는 경우 나중에 항상 허용할 수 있습니다.

Instant::now는 const가 될 수 없습니다. 그 함수는 무엇을 반환할까요? 편집의 시간?

그러나 const인 Instant::zero() 또는 Instant::min_value() 가 있을 수 있습니다.

누군가 이것을 안정화하기 위해 수행해야 할 작업을 요약할 수 있습니까? 어떤 결정에 도달해야 합니까? 이 모든 것을 안정화할지 여부?

나는 우리의 const fn 검사가 const fn 내부에서 원하지 않는 것을 실수로 허용/안정화하지 않을 만큼 충분히 엄격하다고 생각합니다.

Rust-lang/rfcs#2272를 통해 패턴과 통합할 수 있습니까? 패턴은 이미 있는 그대로 고통스럽습니다. 더 고통스럽게 만들지 맙시다.

나는 우리의 const fn 검사가 const fn 내부에서 원하지 않는 것을 실수로 허용/안정화하지 않을 만큼 충분히 엄격하다고 생각합니다.

내가 틀렸다면 정정해 주세요. 하지만 해당 검사가 현재 const rvalue 본문에서 허용되는 검사와 동일하지 않습니까? 나는 const FOO: Type = { body }; 와 const FOO: Type = foo(); const fn foo() -> Type { body } 가 임의의 바디를 허용한다는 점에서 동일하다는 인상을 받았습니다.

@sgrif const fn 에는 있지만 const 에는 없는 인수에 대한 우려가 있다고 생각합니다.
또한 장기적으로 오늘날의 const fn 시스템을 유지하려는 것인지도 명확하지 않습니다.

대신 const 제네릭(양방향)을 제안하고 있습니까? (예: <const T> + const C<T> 또는 const C<const T> ?)

컴파일 타임에 모든 표현식을 평가하려고 시도하고 가능하지 않은 경우 패닉을 일으키는 try_const! 매크로를 갖고 싶습니다. 이 매크로는 non-const fns를 호출할 수 있으므로(miri 사용?) std의 모든 함수가 const fn으로 표시될 때까지 기다릴 필요가 없습니다. 그러나 이름에서 알 수 있듯이 언제든지 실패할 수 있으므로 함수가 업데이트되고 이제 const가 될 수 없으면 컴파일이 중지됩니다.

@Badel2 왜 그런 기능을 원하는지 이해하지만 널리 사용하면 크레이트 생태계에 정말 나쁜 영향을 미칠 것이라고 생각합니다. 이렇게 하면 크레이트가 컴파일 시간에 평가 가능한 다른 크레이트의 함수에 따라 달라질 수 있고 크레이트 작성자가 함수 서명에 영향을 주지 않고 컴파일 시간에 평가 가능한 함수를 방지하는 것을 변경하기 때문입니다.

함수가 처음에 const fn 로 표시된 경우 크레이트 작성자는 크레이트를 컴파일하려고 할 때 직접 문제를 발견했을 것이며 주석에 의존할 수 있습니다.

운동장에서만 작동했다면... https://play.rust-lang.org/?gist=6c0a46ee8299e36202f959908e8189e6&version=stable

이것은 빌드된 프로그램에 빌드 시간을 포함하는 비 이식성(사실, 너무 비 이식성이어서 내 시스템에서는 작동하지만 놀이터에서는 작동하지 않지만 둘 다 Linux임) 방법입니다.

이식 가능한 방법은 const 평가에서 SystemTime::now()를 허용하는 것입니다.

( const fn 여부에 관계없이 모든 함수/표현식의 const/compile-time-eval에 대한 인수입니다.)

그것은 include_bytes에서 절대 경로를 금지하는 주장처럼 들립니다 😃

const fn에서 SystemTime::now를 허용하면 시스템 성능, 스케줄러 및 Jupiter의 위치에 따라 const FOO: [u8; SystemTime::now()] = [42; SystemTime::now()]; 에서 무작위로 오류가 발생합니다.

더 나쁜:

const TIME: SystemTime = SystemTime::now();

TIME의 값이 모든 사용 사이트, 특히 증분 컴파일 및 크레이트 전체에서 동일하다는 의미는 아닙니다.

그리고 더 미친 것은 길이가 3인 배열에서 복제 impl을 선택하게 될 수도 있지만 반환 유형이 길이가 4인 배열일 수 있기 때문에 매우 불건전한 방식으로 foo.clone() 를 망칠 수 있다는 것입니다.

따라서 임의의 함수가 호출되도록 허용하더라도 진정한 난수 생성기를 허용하지 않는 것처럼 SystemTime::new()가 성공적으로 반환되도록 허용하지 않습니다.

@SoniEx2 여기에서는 다소 주제를 벗어난 것 같지만, 화물 build.rs 파일을 사용하여 오늘날 이미 이와 같은 것을 구현할 수 있습니다. Cargo Book의 Build Scripts , 특히 코드 생성 사례 연구 섹션을 참조하십시오.

@oli-obk 하나는 API 안전 버전 관리에 관한 것이고 다른 하나는 빌드 환경에 관한 것이기 때문에 완전히 동일한 문제는 아니라고 생각합니다. 그러나 조심스럽게 적용하지 않으면 둘 다 생태계 파손으로 이어질 수 있다는 점에는 동의합니다.

const fn 에서 현재 시간을 가져오는 것을 허용하지 마십시오 . 빌드를 재현할 수 없도록 만드는 더 많은/더 쉬운 방법을 추가할 필요가 없습니다.

어떤 종류의 비결정론(난수, 현재 시간 등)도 const fn 에 허용할 수 없습니다 . 그러면 Rustc는 상수 표현식이 항상 동일한 결과로 평가된다고 가정하기 때문에 이를 허용하면 유형 시스템이 부적절합니다. 동일한 입력. 좀 더 자세한 설명은 여기 를 참조하세요.

https://github.com/rust-lang/rust/issues/24111#issuecomment -376352844와 같은 사례를 처리하는 미래의 방법은 현재 시간을 가져와 일반 숫자로 내보내는 간단한 절차 매크로를 사용하는 것입니다. 문자열 토큰. 절차적 매크로는 비 const Rust 코드가 사용하는 일반적인 이식 가능한 방법으로 시간을 얻을 수 있는 거의 완전히 제한되지 않은 코드입니다.

@rfcbot fcp 병합

나는 이것을 병합할 것을 제안합니다. 왜냐하면 이것은 다소 정상적인 옵션이고 주요 변경 사항이 아니며 우발적인 주요 변경 사항을 방지하기 때문입니다. 정말 나쁜 점은 많은 함수 선언 앞에 const 를 던져야 한다는 것입니다.

@oli-obk 대신 @rfcbot fcp merge - 안정화에 대해 생각하고 문제를 논의할 가치가 있는 것 같습니다.

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

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

우려 사항:

• 디자인 (https://github.com/rust-lang/rust/issues/24111#issuecomment-376829588)
• https://github.com/rust-lang/rust/issues/24111#issuecomment -377133537에 의해 해결된 parallel-const-traits
• 우선순위 (https://github.com/rust-lang/rust/issues/24111#issuecomment-376652507)
• 런타임 포인터 주소(https://github.com/rust-lang/rust/issues/24111#issuecomment-386745312)

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

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

@rfcbot 우려 우선 순위

나는 우리가 어떤 낙진을 다룰 대역폭이 없다고 생각하기 때문에 판 이후까지 이것을 펀트하고 싶을 수도 있습니다.

@rfcbot 은 모든 것을 염려합니다-const

우리는 모든 기능을 const 만들 수 있는 인센티브가 있는 약간의 C++ 세계로 끝납니다.

@oli-obk와의 짧은 토론 요약:

1. 미래에는 거의 모든 함수가 const 로 표시될 수 있습니다. 예를 들어 Vec const #$ 가 될 수 있습니다. 그 세계에서는 const 키워드를 완전히 제거하는 것이 합리적일 수 있습니다. 거의 모든 것이 const 일 수 있으며 함수를 const에서 non으로 변경하려면 최선을 다해야 합니다. -const, 따라서 추론된 constness에 대한 이전 버전과의 호환성 위험은 그다지 높지 않을 것입니다.

2. 그러나 오늘 const 을 제거하는 것은 불가능합니다. 오늘날의 미리는 모든 것을 해석할 수 없으며 프로덕션 단계에서 완전히 테스트되지 않았습니다.

3. 현재 const 를 요구하는 것은 실제로 이전 버전과 호환되며, 이 키워드를 더 이상 사용하지 않고 미래에 추론된 상수로 전환합니다.

1, 2, 3을 함께 사용하면 향후 릴리스에서 상수 평가 가능한 기능 집합을 확장하는 것보다 현재 const 키워드를 안정화하는 것이 좋은 옵션인 것 같습니다. 얼마 후 우리는 모든 것을 평가할 수 있는 철저하게 전투 테스트를 거친 허니 오소리 상수 평가자를 갖게 될 것입니다. 이 시점에서 추론된 const로 전환할 수 있습니다.

낙진 위험: const fn은 야간, 특히 임베디드에서 널리 사용되었습니다. 또한 const fn 검사기는 정적 이니셜라이저 및 상수에 사용되는 검사기와 동일한 검사기입니다(일부 정적 특정 검사 및 함수 인수 제외).

내가 보는 가장 큰 단점은 우리가 기본적으로 const 를 상자 전체에 자유롭게 뿌리는 것을 옹호하고 있다는 것입니다(지금은 미래 아이디어에 대한 @matklad 의 게시물 참조

@rfcbot 은 parallel-const-traits에 대해 걱정합니다.

이것을 안정화하면 Const 가 앞에 있는 병렬 특성 계층 구조를 만드는 많은 상자가 즉시 생성되는 것처럼 느껴집니다. ConstDefault , ConstFrom , ConstInto , ConstClone , ConstTryFrom , ConstTryInto 등 ConstIndex 등을 요구합니다. 그렇게 끔찍하지는 않습니다. 오늘날 Try 로 약간의 문제가 있지만 TryFrom을 안정화하는 것이 도움이 될 것입니다. (https://github.com/rust-lang/rfcs/pull/2237입니까? 모르겠습니다).

( @nrc : 봇이 귀하의 관심사 중 하나만 등록한 것 같습니다)

Parallel-const-traits는 가상의 미래 const-all-the-things 버전에서 간단한 솔루션을 제공합니다. 그들은 그냥 일할 것입니다.

const fn 세계에서 우리가 const fn 특성 메소드(우리는 atm하지 않음)를 허용하지 않는 한 특성 복제로 끝나지 않을 것입니다. 물론 1년 전 libstd가 있었던 상황과 유사한 관련 상수(야간)를 생성할 수 있습니다. 여기서 우리는 개인 필드를 노출하지 않고 statics/constants 내부에 다양한 유형을 초기화하기 위한 많은 상수를 가지고 있었습니다. 그러나 그것은 이미 한동안 일어날 수 있었고 일어나지 않은 일입니다.

분명히 하자면 $#$ const fn #$ 가 없어도 현재 ConstDefault 가 가능하며 나머지 예제( ConstFrom , ConstInto , ConstClone , ConstTryFrom , ConstTryInto ) 이 기능이 안정화된 상태에서도 @oli-obk가 언급한 대로 const 특성 메서드를 추가하지 않기 때문에 불가능합니다.

( ConstDefault 는 연결된 const fn 대신 연결된 const 를 사용하여 가능하지만 내가 아는 한 전력은 동일합니다.)

@scottmcm const fn 특성 정의는 오늘날 불가능합니다(오 @solson 이 이미 언급했습니다).

@eddyb 임의의 아이디어: 특성 정의에 const fn 를 추가하는 대신 const impl 특성을 가능하게 하면 어떻게 될까요? (이 둘은 상호 배타적이지 않습니다.)

@whitequark https://github.com/rust-lang/rfcs/pull/2237 은 각 fn 에서 const impl 를 const fn 로 확장하는 조합을 통해 그 아이디어를 다룹니다. impl , const 의 어떤 메소드도 표시하지 않고 T: const Trait 경계를 충족하기 위해 모든 const 메소드와 함께 impl 허용 특성 정의 자체.

@rfcbot 우려 디자인

우리는 역사적으로 몇 가지 이유로 특정 const fn 시스템을 안정화하기 위해 노력했습니다.

• 현재는 const fn trait const fn 메서드를 제공하는 $ impl 를 지원하지 않습니다(https://github.conf 참조). com/rust-lang/rfcs/pull/2237을 수행하는 몇 가지 방법)
• 이와 관련하여 T: Trait 바인딩된 const fn 를 통해 사용되는 메서드를 별도의 특성 없이 , 가급적이면 컴파일 타임에 사용할 때만 (예: Option::map ) 요청하는 문제가 있습니다.
• 잠재적으로 const-evaluate 가능한 많은 알고리즘, 컬렉션 및 추상화와 함께 const fn 를 사용하는 전체 상자가 있을 수 있습니다( libcore 가 마음에 옴)

이러한 문제의 대부분 또는 대부분을 완화할 수 있는 다양한 디자인 선택이 있습니다(다른 것을 도입하는 비용으로). 예를 들어 다음과 같은 몇 가지가 있습니다.

• 주석이 필요 하지 않고 컴파일러 오류를 내보내고 미리가 평가하지 못합니다.
  
  
  
  • 장점: 더 깨끗한 코드베이스, 관련된 값에 따라 지속적인 평가가 이미 실패할 수 있음
  
  
  • 단점: 언어 수준의 동작 문서 및 semver 경계가 없으므로 miri에서 다른 사람의 코드를 던지고 그들이 만든 사소한 변경을 관찰할 수 있습니다(예: 종속성 중 하나의 패치 버전에 런타임 디버그 로깅이 추가됨). 또한 rvalue 프로모션이 더 어렵습니다.
  
  
• function/impl/module/etc에 따라 위의 동작을 선택하는 방법입니다.
  
  
  
  • 이 함수의 본체는 (적어도 const fn 측면에서) 매크로처럼 작동합니다.
  
  
  • 장점: semver 의미가 없고 일부 분석의 범위를 제한합니다.
  
  
  • 단점: 여전히 훌륭한 문서가 아니며 어떤 동작이 영향을 받아야 하는지 명확하지 않음( 단지 const-evaluatability?), 신체의 모든 변경은 semver-breaking으로 간주될 수 있음
  
  

이렇게 하면 크레이트가 컴파일 시간에 평가 가능한 다른 크레이트의 함수에 따라 달라질 수 있고 크레이트 작성자가 함수 서명에 영향을 주지 않고 컴파일 시간에 평가 가능한 함수를 방지하는 것을 변경하기 때문입니다.

@leoschwarz 이것은 이미 자동 특성의 문제가 아닙니까? 아마도 이에 대한 해결책은 Rust-semverver를 화물과 통합하여 이러한 종류의 의도하지 않은 파손을 감지하는 것입니다.

즉, miri에 (라이브러리 작성자로서) 실수로 초과하는 평가 시간 제한이 있어 컴파일 실패 다운스트림이 발생하는 경우 어떻게 되는지 명확하지 않습니다.

@nrc "everything-const"가 사실이라고 생각하지만 문제는 아닙니다. 예, 우리는 const 많은 것을 표시하게 될 것입니다.

모든 것이 다음과 같이 추론되기를 원하는지 확신이 서지 않는다는 점을 지적하고 싶습니다.
상수 런타임 또는 컴파일 시간이 더 긴지에 대한 결정입니다.
중요한. 때로는 컴파일러가 다음에서 충분히 계산을 수행한다고 생각합니다.
컴파일 시간!

2018년 3월 28일 수요일 오후 2:49, Josh Triplett [email protected]
썼다:

@nrc https://github.com/nrc "everything-const"가 사실이라고 생각하지만 그렇지 않습니다.
이슈. 예, 우리는 const의 거대한 범위를 표시하게 될 것입니다.

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

평가 시간 제한

그 한계는 곧 사라진다.

모든 것이 const로 유추되기를 원하는지 확신이 서지 않는다는 점을 지적하고 싶습니다.

아뇨, 컴파일 타임에 무작위로 계산하지 않을 것입니다. 정적, 상수, 열거형 변이 판별자 및 배열 길이의 본문에서 임의의 것을 계산하도록 허용하십시오.

@rfcbot 이 병렬 상수 특성을 해결했습니다.

수정해주셔서 감사합니다.

그 한계는 곧 사라진다.

엄청난. 이 경우 auto-const-fn(rust-semverver의 일부 통합 또는 파손에 대한 정보를 제공하는 유사 기능과 함께)이 훌륭하게 들리지만 "로깅 추가 및 파손 원인"은 문제가 될 수 있습니다. 버전 번호를 올릴 수는 있지만 유한하지는 않습니다.

로깅 및 인쇄는 상수 모델에서 "정상적인" 부작용입니다. 모두가 동의한다면 우리는 이에 대한 해결책을 찾을 수 있을 것입니다. 파일에 쓸 수도 있습니다(실제로는 아니지만 마치 우리가 한 것처럼 행동하고 모든 것을 버립니다).

부작용을 말없이 버리는 것이 정말 걱정입니다.

RFC를 생성하면 이에 대해 논의할 수 있습니다. 지금은 상수에 "부작용"이 있을 수 없습니다. 주제는 const fn 안정화와 직교합니다.

나는 유추에 대한 "그냥 semver 경고를 수행하십시오"접근 방식에 대해 약간 걱정합니다.
일관성. constness에 대해 생각해 본 적이 없는 크레이트 작성자가 본다면
"경고: 방금 변경한 사항으로 인해 foo()를 호출할 수 없습니다.
이전에는 가능했던 const 컨텍스트"를 사용하면
non-sequitur 및 침묵? 분명히, 이 문제의 사람들은 자주 생각합니다.
어떤 함수가 const가 될 수 있는지에 대해. 그리고 더 많은 사람들이 해주면 좋을텐데
(일단 const_fn이 안정되면). 그러나 의외의 경고가 맞습니다.
그것을 격려하는 방법?

2018년 3월 29일 목요일 오전 4시 36분, Oliver Schneider [email protected]
썼다:

RFC를 생성하면 이에 대해 논의할 수 있습니다. 지금은 그냥
상수에 "부작용"이 있을 수 없습니다. 주제는 직교
안정화 const fn

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

명시적 const fn은 많은 API를 성가시게 하고 혼란스럽게 할 수 있다고 생각합니다. 그러나 암시적으로 가정하는 대신 실행하기에는 너무 많은 문제가 있다고 생각합니다.

• 부작용을 버리면 const 또는 non const라고 하는 경우 코드가 다르게 동작(예: 파일을 작성한 다음 읽기)할 수 있습니다.
• extern 함수를 호출하면 항상 부작용이 있을 수 있으므로 안전하지 않은 코드는 const fn으로 유추될 수 없습니다.
• 일반 코드에 대해 const fn을 유추할 수 있는 경우는 언제입니까? 이것이 monomorphization 시간에 수행됩니까?

그러나 누군가가 한 번만 변경해도 실수로 많은 코드를 알아채지 못한 채 실수로 깨뜨릴 수 있다는 점을 명시하지 않는 것이 가장 큰 문제입니다. 이것은 특히 Rust 생태계에서 흔히 볼 수 있는 긴 종속성 그래프와 관련이 있습니다. 함수 서명에 대한 명시적인 변경이 필요한 경우 이것이 주요 변경 사항임을 더 쉽게 알 수 있습니다.

아마도 이러한 기능은 #![infer_const_fn] 또는 이와 유사한 상자의 루트에 추가할 수 있는 상자 수준 구성 플래그로 구현될 수 있으며 영원히 옵트인 상태를 유지할 수 있습니다. 플래그가 추가되면 const fn은 가능한 경우 크레이트에서 추론되고 문서에도 반영됩니다(그리고 호출된 함수도 const fn이 되어야 함). 크레이트 작성자가 이 플래그를 추가하면 일종의 신중을 기하겠다는 약속 버전 관리에 대해 그리고 아마도 rust-semverver가 강제될 수도 있습니다.

거꾸로 해보면 어떨까요?

const fn 대신 side fn을 사용하십시오.

그것은 여전히 ​​​​명시적이며 (명시적으로 호환성을 깨고 측면 fn을 호출하려면 측면 fn을 넣어야 함) 혼란을 제거합니다. (일부) 내장 및 asm이 있는 모든 것은 fn이 될 것입니다.

이전 버전과 호환되지는 않지만 에디션에 추가할 수 있을까요?

2018년 3월 30일 오전 2:43:06 GMT+08:00, "Soni L." [email protected] 은 다음과 같이 썼습니다.

거꾸로 해보면 어떨까요?

const fn 대신 side fn을 사용하십시오.

여전히 명시적입니다(side fn을 호출하려면 side fn을 넣어야 합니다.
명시적으로 호환성을 깨고), 혼란을 제거합니다. (일부)
내장 및 asm이 있는 모든 것은 fn이 됩니다.

--
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/24111#issuecomment -377333542

--
K-9 Mail을 사용하여 Android 기기에서 보냈습니다. 제 간략한 설명을 부탁드립니다.

더 큰 문제는 대부분의 프로그래밍 언어가 하는 것이 아니기 때문에 초보자에게 큰 충격을 줄 것이라는 것입니다.

@whitequark 나는 단지 그렇게 하는 것("부작용 없애기")에 동의하지 않습니다. @oli-obk가 미래의 확장에 대해 이야기하고 있었던 것 같습니다. 그러나 내가 있었던 토론에서 나는 다음을 알고 있습니다.

• "결정론적 부작용"(불순한 데이터를 반환 하지 않음)을 구별할 수 있습니다.
• 예를 들어 "컴파일 타임에 데이터를 기록"하려는 경우 특수 API를 사용할 수 있습니다.
  
  
  
  • 증분 주문형 컴파일이 반드시 일관된 출력을 초래하지 않기 때문에 원하는 외부 결정성 수준에 따라 매우 어렵습니다.
  
  
• 특히, 우리는 현재 존재하고 globals / C FFI를 사용하는 것을 만지지 않을 것입니다.

편집 : 토론이 탈선하지 않도록, 예:

부작용을 버리면 const 또는 non const라고 하는 경우 코드가 다르게 동작(예: 파일을 작성한 다음 읽기)할 수 있습니다.

우리는 (아마도?) 모두 @oli-obk가 그런 부작용을 버리는 것에 관해 잘못 이야기했다고 가정할 수 있습니다.

이러한 기능은 크레이트 루트에 추가할 수 있는 크레이트 수준 구성 플래그로 구현될 수 있습니다.

이는 https://github.com/rust-lang/rust/issues/24111#issuecomment -376829588에서 이전 제안의 두 번째 예의 하위 집합 입니다.
범위가 지정된 "구성 플래그"가 있는 경우 사용자는 보다 세분화된 범위 IMO를 선택할 수 있어야 합니다.

거꾸로 해보면 어떨까요?
const fn 대신 side fn을 사용하십시오.
그것은 여전히 ​​​​명시적이며 (명시적으로 호환성을 깨고 측면 fn을 호출하려면 측면 fn을 넣어야 함) 혼란을 제거합니다. (일부) 내장 및 asm이 있는 모든 것은 fn이 될 것입니다.

https://github.com/rust-lang/rust/issues/24111#issuecomment -376829588에서 저는 전체 라이브러리 가 "all const fn " 또는 "all side fn 수 있음을 지적하려고 했습니다. ".
함수 선언이 아니라 범위가 지정된 경우 향후 버전에서 작동할 수 있습니다 .
그러나 "본문에서 추론" 시맨틱이 없으면 옵트인 side fn 에 대해서도 특성 상호작용을 설계해야 하므로 아무 것도 얻지 못하고 잠재적으로 엄청난 마찰을 일으킬 수 있습니다.

Kenton Varda의 "유해한 것으로 간주되는 싱글톤" 글의 섹션 3.3이 여기에 관련이 있는 것 같습니다(솔직히 전체 내용을 읽을 가치가 있습니다).

디버그 로깅은 어떻습니까?

실제로 모든 사람은 디버그 로깅이 코드의 모든 부분에서 사용 가능해야 함을 인정합니다. 우리는 그것에 대해 예외를 만듭니다. 이 예외에 대한 정확한 이론적 근거는 관심 있는 사람들을 위해 몇 가지 방법으로 제공될 수 있습니다.

보안 관점에서 디버그 로깅은 양성 단일 항목입니다. 쓰기 전용이므로 통신 채널로 사용할 수 없습니다. 디버그 로깅은 프로그램의 정확성을 결정짓는 요소가 아니기 때문에 디버그 로그에 기록함으로써 어떤 종류의 손상도 일으키는 것은 분명히 불가능합니다. 악성 모듈이 로그를 "스팸"하더라도 디버그 로그는 일반적으로 각 메시지를 생성한 모듈을 정확히 식별하기 때문에 해당 모듈의 메시지를 쉽게 필터링할 수 있습니다(때로는 스택 추적을 제공하기도 함). 따라서 제공하는 데 문제가 없습니다.

디버그 로깅이 가독성, 테스트 가능성 또는 유지 관리 가능성에 해를 끼치지 않는다는 것을 보여주기 위해 유사한 주장을 할 수 있습니다.

디버그 로깅에 대한 또 다른 이론적 정당화는 디버그 로그 기능이 실제로는 디버거에서 관찰되는 무작동이라는 것입니다. 디버거가 실행되고 있지 않으면 함수는 아무 작업도 수행하지 않습니다. 일반적으로 디버깅은 분명히 전체 개체 기능 모델을 깨뜨리지만 분명히 권한 있는 작업이기도 합니다.

"[디버깅을 위한] 솔루션을 알아낼 수 있습니다"에 대한 내 진술은 실제로 const에서 호출할 수 있지만 인쇄 형식이 있는 잠재적인 미래 API를 언급한 것입니다. 플랫폼별 인쇄 작업을 무작위로 구현하는 것은(인쇄/디버그 명령문이 있는 기존 코드를 const로 만들 수 있도록) const 평가자가 수행해야 하는 작업이 아닙니다. 이것은 순전히 옵트인이며 다른 관찰 가능한 동작(예: 런타임 시 const eval 및 명령줄/파일 출력의 경고)을 명시적으로 갖지 않습니다. 정확한 의미는 미래의 RFC에 남겨지며 일반적으로 const fn과 완전히 직교하는 것으로 간주되어야 합니다.

const impl Trait 및 T: const Trait 에 중대한 단점이 있습니까?

const 주위에 스프레이를 더 많이 뿌리는 것 외에 일부 특성 메서드만 const일 수 있으며 더 세밀한 제어가 필요합니다. 나는 그것을 지정하는 깔끔한 구문을 모릅니다. 아마도 where <T as Trait>::some_method is const ( is 은 문맥 키워드일 수 있음).

다시 말하지만, const fn과 직교합니다.

[u8; SizeOf<T>::Output]

const와 side fns가 분리된 경우 실제 설계 고려 사항을 고려해야 합니다. 그것들을 분리하는 가장 쉬운 방법은 const fns를 오늘날 우리가 가지고 있는 튜링 완전 유형 시스템의 확장으로 만드는 것입니다.

또는 const fns를 실제로 const로 만듭니다. 모든 const fn은 모든 매개변수가 const 제네릭인 것처럼 평가되어야 합니다.

이것은 그들이 현재 서 있는 const fns에 대해 개인적으로 추론할 수 없기 때문에 추론하기가 훨씬 더 쉽습니다. 튜링 완전 유형, 매크로, 일반 fns 등에 대해 추론할 수 있지만 사소한 세부 사항이라도 의미를 완전히 변경하기 때문에 const fn에 대해 추론하는 것이 불가능하다는 것을 알았습니다.

사소한 세부 사항조차도 의미를 완전히 변경하기 때문입니다.

자세히 설명해 주시겠습니까? const fn 포인터, const 특성 경계와 같은 확장을 의미합니까? const fn 제안서에서 사소한 세부 사항을 볼 수 없기 때문입니다.

또는 const fns를 실제로 const로 만듭니다. 모든 const fn은 모든 매개변수가 const 제네릭인 것처럼 평가되어야 합니다.

그것이 우리가 컴파일 타임에 하는 일입니다. 런타임에 함수는 다른 함수처럼 사용됩니다.

문제는 사소한 세부 사항이 const eval을 런타임 eval로 바꿀 수 있다는 것입니다. 이것은 처음에는 큰 거래처럼 보이지 않을 수 있지만, 그럴 수 있습니다 .

함수 호출이 모두 const fns이기 때문에 정말 길다고 가정해 봅시다. 그리고 그것을 여러 줄로 나누고 싶습니다.

따라서 let 몇 개를 추가합니다.

이제 프로그램을 실행하는 데 20배 더 오래 걸립니다.

@SoniEx2 배열의 크기( $N in [u8; $N] )는 항상 컴파일 타임에 평가됩니다. 해당 표현식이 const 가 아니면 컴파일이 실패합니다. 반대로 let x = foo() const fn foo 합니다 const fn ). 컴파일 타임에 일부 표현식을 평가한 결과의 이름을 지정하려면 const 항목이 필요합니다.

이제 프로그램을 실행하는 데 20배 더 오래 걸립니다.

const fn이 작동하는 방식은 전혀 아닙니다!

const fn 함수를 선언하고 그 안에 let 바인딩을 추가하면 코드 컴파일이 중지됩니다.

const fn const 를 제거하면 획기적인 변경이며 const , static 또는 배열 길이 내부에서 해당 함수의 모든 사용을 중단합니다. 런타임 코드이고 const fn 를 실행한 코드는 컴파일 타임에 실행되지 않습니다. 일반적인 런타임 함수 호출이므로 느려지지 않습니다.

편집: @SimonSapin 이 저를 이겼습니다 :D

Const fn은 가능한 경우 컴파일 타임에 평가됩니다.

그건,

const fn random() -> i32 {
    4
}

fn thing() -> i32 {
    let i = random(); // the RHS of this binding is evaluated at compile-time, there is no call to random at runtime.
}

이제 인수를 취하는 const fn이 있다고 가정해 보겠습니다. 이것은 컴파일 타임에 평가됩니다.

fn thing() {
    let x = const_fn_with_1_arg(const_fn_returns_value());
}

이로 인해 const_fn_with_1_arg 가 런타임에 평가됩니다.

fn thing() {
    let x = const_fn_returns_value();
    let y = const_fn_with_1_arg(x); // suddenly your program takes 20x longer to run, and compiles 20x faster.
}

@eddyb "최소 const fn"이 모든 잠재적인 향후 확장과 호환된다는 관찰로 디자인 문제를 해결할 수 있는지 궁금합니다. 즉, 내 이해는 우리가 안정화되기를 원한다는 것입니다.

자유 함수와 고유 메소드를 const로 표시하여 상수 컨텍스트에서 상수 인수와 함께 호출할 수 있습니다.

이것은 "특성에 대한 const 효과" 디자인과 거의 완벽하게 호환되는 것으로 보입니다. 나중에 const 선택 사항으로 만들 수 있기 때문에 "추론된 const" 디자인과도 호환됩니다.

현재 "minimal const fn" 제안과 호환되지 않는 대체 미래 디자인이 있습니까?

@nrc

rfcbot이 귀하의 everything-const 우려 사항을 등록하지 않았음을 참고하십시오(댓글당 하나의 우려 사항!) 그러나 이는 내 이전 의견(TL;DR: 현재 최소 제안)에서 해결된 설계 문제의 하위 집합인 것 같습니다. 모든 것과 완벽하게 호환되므로 향후 const 키워드를 선택 사항으로 만들 수 있습니다.

우선 순위/낙진 문제에 관해서는 우리가 논의한 것과 아직 문서화하지 않은 것을 문서화하고 싶습니다.

• const fn foo(x: i32) -> i32 { body } 는 const FOO: i32 = body; 에 비해 상대적으로 작은 추가이므로 낙진 위험이 적습니다. 즉, 실제로 const fn 를 구현하는 대부분의 코드는 이미 안정적인 컴파일러에서 열심히 작동하고 있습니다.

• 임베디드 작업 그룹은 const fn을 심하게 원합니다 :)

또한 const fn 를 안정화 하지 않으면 라이브러리에서 최적이 아닌 API가 확산될 수 있습니다. 왜냐하면 그들은 const fns의 부족을 해결하기 위해 ATOMIC_USIZE_INIT 와 같은 트릭을 사용해야 하기 때문입니다.

하자 나는 = random(); // 이 바인딩의 RHS는 컴파일 타임에 평가되며 런타임에는 random에 대한 호출이 없습니다.

아니요, 전혀 일어나지 않습니다. 일어날 수 있지만(그리고 llvm이 아마도 이것을 하고 있을 것입니다), 실제로 발생하는 경험적 방법에 의존하는 컴파일러 최적화를 기대할 수는 없습니다. 컴파일 타임에 무언가를 계산하고 싶다면 const 에 붙이면 그 보장을 받을 수 있습니다.

그래서 const fn은 const에서만 평가되며, 그렇지 않으면 기본적으로 쓸모가 없습니까?

그렇다면 const와 non-const fn을 엄격하게 분리하지 않는 이유는 무엇입니까?

의미 체계는 의도적으로 컴파일 시간과 런타임 항목을 혼합하기 때문에 엉망입니다.

그래서 const fn은 const에서만 평가되며, 그렇지 않으면 기본적으로 쓸모가 없습니까?

그것들은 쓸모가 없으며, 그렇지 않으면 다른 함수와 마찬가지로 런타임에 실행됩니다. 이것은 당신이 const 평가에 있는지 여부에 따라 Rust의 다른 "하위 언어"를 사용할 필요가 없다는 것을 의미합니다.

그렇다면 const와 non-const fn을 엄격하게 분리하지 않는 이유는 무엇입니까?

const fn 에 대한 전체 동기는 이러한 분리가 없는 것입니다. 그렇지 않으면 두 본체가 동일하더라도 모든 종류의 함수를 복제해야 합니다. AtomicUsize::new() + AtomicUsize::const_new() .

libcore 의 90%를 const eval용으로 한 번, 런타임용으로 한 번, 두 번 작성하시겠습니까? 다른 많은 상자도 마찬가지일 것입니다.

AtomicUsize::Of<value> 생각했습니다. 그리고 예, 알 수 없는 보장을 받는 것보다 모든 것을 두 번 작성해야 합니다. (게다가 이것은 무언가가 const eval'되는지 여부에 따라 다르게 작동하지 않습니다.)

const 평가를 보장하기 위해 const fn에서 const를 선언할 수 있습니까(재귀적 const fn의 경우)? 아니면 const 제네릭을 거쳐야 합니까? 등.

@SoniEx2 는 const fn 을 활용하고 두 함수 중 하나가 const 가 아닌 경우 컴파일 시간 오류로 전환하기 위해 예제를 작성하는 방법에 대한 예입니다.

fn thing() {
    const x: u32 = const_fn_returns_value();
    const y: u32 = const_fn_with_1_arg(x);
}

(놀이터에서 전체 실행 예제)

유형 추론이 없기 때문에 인체공학적이지 않지만 향후 변경될 수 있습니다.

알 수 없는 보장을 받는 것보다

너무 친절하고 불분명하다고 생각되는 부분에 대한 몇 가지 예를 들어 주시겠습니까?

const 평가를 보장하기 위해 const fn에서 const를 선언할 수 있습니까(재귀적 const fn의 경우)? 아니면 const 제네릭을 거쳐야 합니까? 등.

const fn 의 요점은 컴파일 타임에 마술처럼 평가하지 않는다는 것입니다. 컴파일 타임 에 평가할 수 있기 때문입니다.

Rustc가 llvm을 기반으로 했기 때문에 컴파일 타임에 마술처럼 평가하는 것은 이미 일어나고 있습니다. 그래서 ... 정확히 언제 ocaml에서 구현이 중단되었습니다. 아무도 Rustc에서 지속적인 전파를 제거하고 싶어하지 않는다고 생각합니다.

const fn 는 어떤 식으로든 지속적인 전파에 영향을 미치지 않습니다. 실수로 const가 전파될 수 있는 함수가 있고 llvm이 그렇게 하고 더 이상 const 전파할 수 없는 방식으로 해당 함수를 변경했다면 llvm은 그렇게 하지 않습니다. 이것은 const 를 함수에 연결하는 것과 완전히 독립적입니다. llvm에는 const fn 와 fn 사이에 차이가 없습니다.

동시에 Rustc는 const 를 fn 에 첨부할 때 동작을 전혀 변경하지 않습니다(함수가 유효한 const fn이고 그렇게 한 후에도 여전히 컴파일된다고 가정). 이제부터 상수로 이 함수를 호출할 수만 있습니다.

저는 LLVM에 대해 생각하고 있는 것이 아니라 녹에 대해 생각하고 있습니다. 여기서 LLVM은 나에게 중요하지 않습니다.

@SoniEx2

Const fn은 가능한 경우 컴파일 타임에 평가됩니다.

이것은 정확하지 않습니다. const fn , 특정 컨텍스트에서 호출되면 컴파일 타임에 평가됩니다. 이것이 가능하지 않다면 하드 오류가 있는 것입니다. 다른 모든 컨텍스트에서 const 부분은 전혀 중요하지 않습니다.

const fn 가 필요한 컨텍스트의 예로는 배열 길이가 있습니다. [i32; 15] 를 쓸 수 있습니다. 컴파일러가 7 를 계산할 수 있기 때문에 [i32; 3+4] 를 작성할 수도 있습니다. [i32; read_something_from_network()] 를 쓸 수 없습니다. 그게 무슨 의미가 있을까요? 이 제안을 사용하면 foo 가 const fn $ 인 경우 $ [i32; foo(15)] 를 작성할 수 있습니다. 이는 네트워크 액세스와 유사하고 덧셈에 가깝도록 합니다.

이것은 프로그램이 실행될 때 실행되거나 실행될 코드에 관한 것이 아닙니다 . "컴파일 타임에 평가할 수 있음"이 없습니다. "컴파일 타임에 평가하거나 컴파일을 중단해야 함"이 있습니다.

RFC도 읽어보십시오: https://github.com/rust-lang/rfcs/blob/master/text/0911-const-fn.md

const fn 주석을 사용하는 대신 추론된 속성이라면 어떻게 될까요? 소스 코드에서는 명시적이지 않지만 자동 생성 문서에서는 자동으로 레이블이 지정될 수 있습니다. 이렇게 하면 라이브러리 작성자가 코드를 변경할 필요 없이 const 로 간주되는 항목을 궁극적으로 확장할 수 있습니다. 처음에는 const fn 가 현재 지원하는 모든 것으로 추론이 제한될 수 있습니다(let 바인딩이 없는 순수하고 결정적인 함수).

이 접근 방식에서는 결과가 const 변수에 바인딩된 경우 컴파일 타임에 평가가 발생하고 그렇지 않으면 런타임에 평가가 발생합니다. 이것은 함수가 평가될 때 호출자(호출자보다)에 대한 제어를 제공하기 때문에 더 바람직해 보입니다.

이것은 이미 상당히 철저하게 논의되었습니다. 그 접근 방식의 단점은 실수로 다른 방향으로 가기가 더 쉽다는 것입니다. 누군가 const 컨텍스트에서 라이브러리 함수를 사용하고 있을 수 있지만 라이브러리 작성자가 더 이상 const 을 사용하지 않도록 만들 수 있습니다.

흠 그게 문제지...

편집: const fn 까지 가지 않고 내가 생각할 수 있는 유일한 해결책은 옵트아웃 주석을 사용하여 라이브러리 작성자가 const 를 중단할 수 있는 권한을 보유할 수 있도록 하는 것입니다. 네스 호. 그래도 const fn 를 사방에 뿌리는 것보다 나은지 잘 모르겠습니다. 유일한 실질적인 이점은 const 의 확장된 정의를 보다 신속하게 채택하는 것입니다.

편집 2: 나는 그것이 하위 호환성을 깨뜨릴 것이라고 생각하므로 초보자가 아닙니다. 옆길에 죄송합니다.

그래서... 토론은 끝났습니다. 요약하자면:

rfcbot 댓글은 https://github.com/rust-lang/rust/issues/24111#issuecomment -376649804입니다.

현재 우려 사항

• 이것은 우선 순위가 아니며 2018 릴리스는 이미 우리 판에 충분했습니다.
• 모든 것을 const 표시하기 시작합니다. 이는 성가신 일입니다.
• 이것이 우리가 약속하고 싶은 디자인입니까?

나는 const fn 이 오랫동안 밤마다 구운 것을 제외하고는 우선 순위 + 낙진 우려에 대해 정말로 말할 수 없습니다.

다른 두 점은 밀접하게 관련되어 있습니다. @eddyb 의 디자인(https://github.com/rust-lang/rust/issues/24111#issuecomment-376829588 내가 이해한 대로)은 const fn 가 아니라 #[const] 물건을 때릴 수 있는

#[const]
mod foo {
    pub fn square(i: i32) -> i32 { i * i }
}
#[const]
fn bar(s: &str) -> &str i{ s }
#[const]
fn boo() -> fn(u32) -> u32 { meh }
fn meh(u: u32) -> u32 { u + 1 }

그리고 그것은 재귀적으로 그것으로 표시된 모든 곳으로 들어가므로 #[const] 모듈 내부의 모든 함수는 #[const] fn 입니다. #[const] fn 내부에 선언된 함수도 #[const] fn 입니다.

이렇게 하면 일부 상자가 lib.rs 에 #![const] 를 치고 끝낼 것이기 때문에 필요한 주석 수가 줄어듭니다.

해당 디자인에서 볼 수 있는 문제(하지만 이러한 문제는 종종 const fn 에도 존재함):

• #[const] 모듈 트리 내부 깊숙이 몇 가지 비 const 함수를 선언할 수 있기를 원할 수 있으므로 옵트아웃 지원이 필요할 수 있습니다.
• 인수/반환 유형 위치에서 #[const] fn 에 대한 함수 포인터는 $ #[const] fn 여야 합니까?
  
  
  
  • 다시, 옵트 아웃이 필요할 것입니다
  
  

우리는 이러한 것들에 대해 생각할 필요가 있으므로 const eval 동안 함수 포인터를 통해 함수를 호출할 수 있기를 원하는 미래 버전과 호환되지 않는 시스템을 설계하지 않습니다.

특정 디자인을 제안한 것이 아니라 알려진 몇 가지 그럴듯한 방향을 나열했을 뿐입니다.
원래 아이디어는 const 에 국한되지 않고 일반화된 "기능의 본문 노출" 속성이었지만 가능한 많은 변형이 있으며 그 중 일부는 좋을 수도 있습니다 .

편집 : (이 사실을 잊고 싶지 않음) @solson 은 Lean이 @pattern 와 같은 속성을 갖고 있어 함수 본문에서 다양한 것을 자동으로 파생시키는 방법을 보여주었습니다.

@oli-obk unsafe 는 속성을 사용하지 않기 때문에 속성을 사용해서는 안 된다고 생각합니다.
또한 현재 async 도 마찬가지입니다. 그리고 try { .. } try fn 를 도입하면 속성 기반이 아닌 또 다른 것이 있습니다. 나는 우리가 효과와 같은 일을 가능한 한 일관되게 유지하려고 노력해야 한다고 생각합니다. 속성 사용 여부. #[target_feature(..)] 는 전체적인 일관성에 주름을 줍니다.

추신: const mod { .. } 를 사용하여 #![const] 정도의 효과를 얻을 수 있습니다. 이것은 try mod , async mod , unsafe mod 에도 적용될 수 있습니다.

나는 항상 특별한 유형의 일에 기댈 것입니다.

struct SizeOf<T>;

impl<T> SizeOf<T> {
    const intrisic Result: usize;
}

새로운 구문으로 새로운 개념을 배우는 것보다 기존 구문을 사용하여 새로운 유형을 배우는 것이 더 쉽습니다.

나중에 런타임에 유형 시스템을 지원할 수 있습니다.

fn sq(v: i32) -> i32 {
    Square<v>::Result
}

컴파일 타임에 유형, 컴파일 타임 또는 런타임에 const 제네릭.

그래서... 더 나은 디자인이 있을 수 있다는 사실을 무시하는 것이 좋습니다.

1. 에 대해 추론하기 쉽습니다.
2. 더 관대한 디자인과 앞으로 호환 가능
3. 역사적으로 불안정한 코드에서 큰 성공을 거두기 위해 사용되었으며 주요 불만 사항은 기능이 충분하지 않다는 것입니다.
4. 추가를 허용하는 본문이 있는 아직 주석 처리되지 않은 함수에 주석을 추가하도록 제안하기 위해 린트될 수 있습니다.
5. 저는 개인적으로 병합 요청에 게시된 것처럼 다년간의 시험 기간 없이 안정화할 수 있는 유일한 디자인이라고 봅니다.
6. 각각에 대해 사용자 정의 코드를 요구하는 대신 런타임 및 const eval 코드 간에 코드를 공유할 수 있습니다.

나중에 런타임에 유형 시스템을 지원할 수 있습니다.

그것은 의존적 타이핑이며, 런타임에 const fn 를 호출하는 동안 오늘날에는 잘 작동합니다.

@oli-obk 특성은 어떻습니까? 트레이트의 impl 중 일부 에서만 const fn 인 트레이트 메서드에 대해 무엇을 할 것인지에 대한 아이디어 없이 const fn 를 안정화하고 싶지 않습니다.

@eddyb 는 새로운 const 경계와 메서드를 신속하게 작성해야 하는 것 같습니다. :)

@Centril 내 요점은 속성 제안(키워드 사용 여부에 관계없이)이 특성 메소드를 처리하는 훨씬 더 다른 접근 방식을 초래한다는 것이며, 우리는 그것을 비교 해야 합니다 .
현재의 const fn 접근 방식은 간단하고 확장 가능한 것처럼 보일 수 있지만 실제로 확장할 때는 그렇지 않습니다 .

일반 const + const 제네릭:

intrinsic const SizeOf<T>: usize;

const Pow<const V: usize>: usize = V*V;

@eddyb 저는 const fn 디자인과 완벽하게 호환되는 다양한 솔루션을 염두에 두고 있습니다. 나는 그것을 쓸 것이다.

와, 이제 막 시작한지 ​​2년이 된 걸 봤습니다. 안정화 날짜가 예상됩니까? 이 확장이 안정화되기를 기다리기 때문에 마구간 에서 거의 사용할 수 있는 상자가 있습니다. :)

@rfcbot 은 런타임 포인터 주소와 관련이 있습니다.

다른 문제에서는 const fn 에서 참조 투명성을 원하는지 여부에 대한 질문이 제기되었으며 원시 포인터의 주소가 비결정론적 오라클로 사용되는 문제가 나타났습니다. https://github.com/rust- lang/rust/issues/49146#issuecomment -386727325. 여기에 설명된 솔루션이 있지만 안정화 전에 일부 원시 포인터 작업을 unsafe (오늘날 허용되는 몇 개인지 확실하지 않음) 만드는 작업이 포함됩니다.

@eddyb E0018 은 const fn 에도 적용되지 않나요?

C 방식은 상대적(즉, 개체 내부)이 아니면 개체 포인터가 모두 0이 되도록 허용되고 런타임에 어떻게든 추적된다는 것입니다.

Rust가 C의 앨리어싱 규칙을 지원하는지 확실하지 않습니다.

@sgrif 상수에 대해 발생하는 많은 오류는 조만간 사라질 것입니다 - miri는 값이 표시되는 유형을 신경 쓰지 않습니다. usize 값에 있는 추상 위치는 여전히 추상 위치입니다. (그리고 포인터로 캐스팅하면 원래 포인터를 다시 얻을 수 있습니다).

방금 확인했고 지금 은 정수에 대한 포인터 캐스팅과 포인터 간의 비교 연산자가 상수 컨텍스트에서 금지됩니다. 그러나 이것은 우리가 생각한 것입니다 . 나는 여전히 두렵습니다.

@eddyb 충분합니다. 그러나 const fn 에 도달한 우려 사항은 오늘 이미 const 블록에 도달했을 것으로 예상합니다.

@sgrif 차이점은 const (제네릭 유형 매개변수에 의존하는 연관된 const 도 포함)은 miri에서 컴파일 타임에 완전히 평가 되는 반면 const fn 는 const fn 런타임 호출.
따라서 참조 투명성을 정말로 원하면 miri에서 문제가 없더라도 런타임 비결정성을 유발할 수 있는 것들을 (적어도 안전한 코드에서) 허용하지 않도록 해야 합니다.
예를 들어 NaN 페이로드 때문에 float 비트를 가져오는 것 또한 문제가 될 수 있음을 의미합니다.

미리에서 해야 할 일:

모든 포인터는 상대가 아닌 경우 0입니다. 예:

#[repr(C)]
struct X {
    a: usize,
    b: u8,
}
let x = X { a: 1, b: 2 };
let y: usize = 3;
assert_eq!(&x as *const _ as usize, 0);
assert_eq!(&x.a as *const _ as usize, 0);
assert_eq!(&x.b as *const _ as usize, 8);
assert_eq!(&y as *const _ as usize, 0);

그런 다음 미리 평가에서 추적합니다. 포인터에서 포인터로 다시 사용하는 것과 같은 일부 항목은 UB이지만 허용하지 않기 쉽습니다(사용을 포인터로 변환하는 것을 금지합니다. 런타임/평가 시간에 이미 포인터를 추적하고 있기 때문입니다).

float 비트의 경우 NaN 정규화?

나는 그 두 가지 모두가 모든 것을 결정적으로 만들 것이라고 생각합니다.

예를 들어 NaN 페이로드 때문에 float 비트를 가져오는 것 또한 문제가 될 수 있음을 의미합니다.

완전한 참조 투명성을 위해서는 모든 float 연산을 안전하지 않게 만들어야 한다고 생각합니다.

부동 소수점 결정론은 어렵다

여기서 가장 중요한 점은 LLVM의 옵티마이저가 부동 연산의 순서를 변경할 수 있고 변경할 수 있을 뿐만 아니라 결합된 opcode가 있는 연산을 ~수행~할 수 있다는 것입니다. 이러한 변경 사항 은 실제 차이가 미미하더라도 작업 결과에 영향을 미칩니다. 이는 miri가 llvm 최적화되지 않은 mir를 실행하는 반면 대상은 기본 코드와 다른 의미 체계를 갖는 llvm에 최적화되고 재정렬될 수 있으므로 참조 투명성에 영향을 미칩니다.

참조 투명성이 얼마나 중요한지에 대한 결정이 내려질 때까지 현재로서는 float가 없는 첫 번째 안정적인 const fn 기능에 동의하지만 const fn이 해당 논의로 인해 느려지거나 차단되는 것을 원하지 않습니다.

여기서 가장 중요한 점은 LLVM의 옵티마이저가 부동 연산의 순서를 변경할 수 있고 변경할 뿐만 아니라 결합된 opcode가 있는 퓨즈 연산을 수행한다는 것입니다. 이러한 변경 사항은 실제 차이가 미미하더라도 작업 결과에 영향을 미칩니다.

Fusing 연산(나는 당신이 mul-add를 참조한다고 가정)은 결과의 반올림을 변경하기 때문에 fast-math 플래그 없이는 허용되지 않거나 수행되지 않습니다. LLVM은 IEEE 호환 하드웨어를 대상으로 할 때 "기본 부동 소수점 환경"에서 설정한 제한 내에서 부동 소수점 연산의 정확한 의미를 유지하기 위해 매우 주의합니다.

LLVM이 보존하려고 하지 않는 두 가지는 NaN 페이로드와 NaN의 신호성입니다. 두 가지 모두 기본 fp 환경에서 관찰할 수 없기 때문입니다. 따라서 우리가 금지해야 하는 float의 비트를 검사해야만 합니다. (그리고 LLVM이 이에 대해 더 주의를 기울였다 하더라도 하드웨어는 NaN 페이로드를 처리하는 방식도 다양하므로 LLVM에 고정할 수 없습니다.)

컴파일러의 결정이 부동 소수점 결과에 영향을 미칠 수 있는 다른 주요 사례는 x87 (SSE 이전) 코드에서 유출 및 다시 로드의 위치입니다. x87은 기본적으로 중간 결과의 경우 80비트로 반올림하고 저장소의 경우 32 또는 64비트로 반올림하기 때문에 이것은 대부분 문제입니다. 올바르게 반올림된 결과를 얻기 위해 각 FPU 명령 전에 반올림 모드를 적절하게 설정하는 것이 가능하지만 실제로는 실용적이지 않으므로 (내 생각에) LLVM은 이를 지원하지 않습니다.

완전한 참조 투명성

내 견해는 우리가 완전한 참조 투명성과 함께 가야 한다는 것입니다. 왜냐하면 이것이 편리함/완벽 함보다 안전/정확함 을 선택한다는 전반적인 Rust 메시지와 어울리기 때문입니다.

참조 투명성은 등식 추론을 가능하게 하는 것과 같은 많은 추론 이점을 추가합니다(최하위까지지만 빠르고 느슨한 추론은 도덕적으로 옳 습니다).

그러나 물론 단점이 있습니다. 완전성 wrt 손실. CTFE. 이것은 참조 투명 const fn 메커니즘이 컴파일 시간에 참조 투명하지 않은 const fn 체계만큼 평가할 수 없다는 것을 의미합니다. 참조 투명성을 고수하지 말자고 제안하는 사람들로부터 이 제안에 대해 가능한 한 많은 구체적인 사용 사례를 제공하여 우리가 절충점을 평가할 수 있도록 요청합니다.

좋아, 당신이 LLVM 포인트에 대해 옳은 것 같습니다. 빠른 수학 모드를 활성화하지 않는 한 실제로 계산상 잘못된 연산을 피하는 것 같습니다.

그러나 부동 소수점 연산이 내부 정밀도와 같이 의존하는 상태 가 여전히 많이 있습니다. CTFE 부동 계산기는 런타임에 내부 정밀도 값을 알고 있습니까?

또한 메모리에 값을 흘리는 동안 내부 값을 ieee754 형식으로 변환하여 정밀도를 변경합니다. 이것은 결과에도 영향을 줄 수 있으며 컴파일러를 사용하여 유출을 수행하는 알고리즘이 지정되지 않았습니까?

@est31 컴파일 시간과 런타임 동작이 다른지 신경 쓰지 않고 반복 호출(고정된 개체 그래프 포함)이 일관되고 전역 부작용이 없다는 것만 가정했습니다.

따라서 참조 투명성을 정말로 원하면 miri에서 문제가 없는 경우에도 런타임 비결정성을 유발할 수 있는 항목을 (적어도 안전한 코드에서) 허용하지 않도록 해야 합니다.

따라서 여기의 목표는 const fn 가 실행 중에 miri가 오류를 발생하더라도 런타임에 결정론적이고 부작용이 없도록 보장하는 것입니다. 적어도 const fn 가 완전히 안전하다면 암호? 나는 그것을 중요하게 생각한 적이 없다, TBH. 이것은 매우 강력한 요구 사항이며 실제로 적어도 ptr-to-int 및 float-to-bits를 안전하지 않게 만들어야 하므로 설명하기 어려울 것입니다. OTOH, 우리는 또한 원시 포인터 비교를 안전하지 않게 만들어야 하며 그것에 대해 만족할 것입니다 :D

이에 대한 동기는 무엇입니까? Rust가 한때 가지고 있었고 잃어버렸던 순도와 효과 시스템을 다시 도입하려고 하는 것 같습니다. 아마도 무게를 지탱하지 않았기 때문일 것입니다(편집: 또는 모든 다른 작업을 수행할 만큼 충분히 유연하지 않았기 때문일 것입니다. 사람들이 그것을 사용하기를 원하는 것, https://mail.mozilla.org/pipermail/rust-dev/2013-April/003926.html 참조).

ptr-to-int는 개체의 시작 부분에서 변환하고 int-to-ptr이 실패하도록 허용하는 경우 안전합니다. 100% 결정적일 것입니다. 모든 호출은 동일한 결과를 생성합니다.

ptr-to-int는 안전하고 int-to-ptr은 안전하지 않습니다. ptr-to-int는 const 평가에서 "예상치 못한" 결과를 허용해야 합니다.

인터프리터/VM에서 NaN 정규화를 실제로 사용해야 합니다. (예를 들어 LuaJIT는 모든 NaN 결과를 표준 NaN으로 만들고 다른 모든 NaN은 패킹된 NaN으로 만듭니다.)

ptr-to-int는 개체의 시작 부분에서 변환하고 int-to-ptr이 실패하도록 허용하는 경우 안전합니다. 100% 결정적일 것입니다. 모든 호출은 동일한 결과를 생성합니다.

런타임에 이것을 구현하는 방법을 제안합니까? (&mut *Box::new(...)) as usize 는 현재 비결정적 함수이며 모두 const fn 여야 합니다. 그렇다면 항상 동일한 값을 반환한다는 의미에서 "런타임에 참조 전송"되도록 하려면 어떻게 해야 할까요?

Box::new는 VM에서 추적된 포인터를 반환해야 합니다.

변환은 컴파일 타임에 0이 됩니다(즉, const 평가에서). 비 const 평가에서는 무엇이든 반환합니다.

추적 포인터는 다음과 같이 작동합니다.

포인터를 할당하고 할당합니다. 할당할 때 VM은 포인터 값을 0으로 설정하지만 포인터의 메모리 주소를 가져와 조회 테이블에 연결합니다. 포인터를 사용할 때 조회 테이블을 통해 이동합니다. 포인터의 값(즉, 포인터를 구성하는 바이트)을 얻으면 0을 얻습니다. 그것이 객체의 기본 포인터라고 가정합니다.

Box::new는 VM에서 추적된 포인터를 반환해야 합니다.

여기서 런타임 동작에 대해 이야기하고 있습니다. 에서와 같이 이것이 바이너리에서 실행되면 어떻게 됩니까? VM이 없습니다.

미리는 이미 이 모든 것을 훌륭하고 완전히 결정적으로 처리할 수 있습니다.

또한 const fn 및 런타임 결정에 대한 우려로 돌아가서: 만약 우리가 그것을 원한다면(우리가 그렇게 할지는 모르겠지만 여전히 우리가 왜 신경을 쓰는지 설명해줄 누군가를 기다리고 있습니다 :D ), 우리는 다음을 선언할 수 있습니다. ptr-to-int 및 float-to-bits는 비 const 연산이 됩니다. 그것에 문제가 있습니까?

@RalfJung 나는 이미 우려 의견에 https://github.com/rust-lang/rust/issues/49146#issuecomment -386727325를 연결했습니다. 아마도 다른 메시지 아래에서 길을 잃었을 수 있습니다. 여기에는 @Centril이 제안한 솔루션에 대한 설명이 포함되어 있습니다( unsafe 작업을 만들고 몇 가지 "올바른 사용"을 화이트리스트에 추가합니다(예: ptr-to-int 및 NaN-정규화 float-to-bits의 경우 offset_of ).

@eddyb 확실히 다양한 솔루션이 있습니다. 내가 요구하는 것은 동기입니다. 거기에서도 찾지 못했습니다.

또한 IRC에서 제 자신을 인용: ptr-to-int 캐스트가 허용되는 경우에도 CTFE 가 결정적이라고 정당하게 주장할 수 있다고 생각합니다. 비결정론을 실제로 관찰하려면 여전히 비 CTFE 코드(예: int로 캐스팅된 ptr 비트 추출)가 필요합니다.

const fn thing() -> usize {
    (*Box::new(0)) as *const _ as usize
}

const X: usize = thing();
const Y: usize = thing();

X == Y입니까?

내 제안으로 X == Y.

foo as *const _ as usize as *const _ 를 깨는 @SoniEx2

동기 부여:
저는 개인적으로 컴파일 시간 동작과 다른 런타임 동작 또는 런타임 시 const fn이 비결정적이라는 문제를 보지 못했습니다. 여기서 안전은 문제가 아니므로 안전하지 않음은 완전히 잘못된 키워드입니다. 이것은 우리가 컴파일 타임 평가에서 완전히 포착하고 있는 놀라운 동작입니다. 일반 기능에서 이미 이 작업을 수행할 수 있으므로 놀라울 일이 없습니다. Const fn은 런타임에 영향을 주지 않고 컴파일 타임에 기존 함수를 평가 가능한 것으로 표시하는 것입니다. 순결에 관한 것이 아닙니다. 적어도 ppl이 "순수한 지옥"에 대해 이야기할 때 얻은 느낌입니다(나는 주변에 없었으므로 오해할 수 있음)

@SoniEx2 네, 항상 X == Y 입니다.

그러나 다음이 있는 경우:

const fn oracle() -> bool { let x = 0; let y = &x as *const _ as usize; even(y) }

fn main() {
    assert_eq!(oracle(), oracle());
}

그러면 런타임에 main 가 패닉할 수 있습니다.

@RalfJung

또는 사람들이 사용하기를 원하는 모든 다양한 작업을 수행할 만큼 충분히 유연하지 않았기 때문에 [..]

그 물건들은 무엇이었습니까? 이것을 확언 없이 평가하기는 어렵다.

ptr-to-int 캐스트가 허용되는 경우에도 CTFE가 결정적이라고 정당하게 주장할 수 있다고 생각합니다.
[...]
비결정론을 실제로 관찰하려면 여전히 비 CTFE 코드(예: int로 캐스팅된 ptr 비트 추출)가 필요합니다.

예, $ const fn const fn 는 컴파일 시간에 실행될 때 여전히 결정적이지만 런타임에 결정적이라고 생각하지 않습니다 fn ) const fn 의 결과가 런타임에 무엇이든 유용할 경우 해당 fn 코드는 실행된 const fn 의 부작용을 관찰합니다.

Haskell에서 순수 코드와 비순수 코드를 구분하는 요점은 "부작용이 있을 것인가"를 지역적으로 결정할 수 있다는 것입니다. 즉, 다음과 같이 주어집니다.

reverse :: [a] -> [a]
reverse []       = []
reverse (x : xs) = reverse xs ++ [x]

putStrLn :: String -> IO ()
getLine :: IO String

main :: IO ()
main = do
    line <- getLine
    let revLine = reverse line
    putStrLn revLine

let revLine = reverse line revLine reverse 에 전달된 상태에만 의존할 수 있으며 이는 line 입니다. 이것은 추론 이점과 깨끗한 분리를 제공합니다.

당시의 효과 시스템이 어땠는지 궁금합니다... 어쨌든 깔끔하게 처리하고 코드를 재사용하려면 const fn , async fn 등이 필요한 것 같습니다. github.com/rust-lang/rfcs/pull/2237 하지만 약간의 변경 사항이 있습니다...) 매개변수는 이에 대한 좋은 생각인 것 같습니다.

필 와들러(Phil Wadler)와 코너 맥브라이드(Conor McBride)의 불후의 명언:

나는 순수해야합니까, 아니면 부정해야합니까?
—필립 와들러 [60]

우리는 '예'라고 말합니다. 순도는 현지에서 선택하는 것입니다.

https://arxiv.org/pdf/1611.09259.pdf

@oli-obk

동일한 인수가 주어진 런타임 또는 컴파일 시간에 실행되는 경우 실행 결과가 const fn 에 대해 다를 수 있다는 이 놀라운 동작을 문서화해야 하는 사람이 부럽지 않습니다.

보수적인 옵션으로 const fn 를 참조 투명으로 안정화하여 참조 투명성/순도에 대한 결정을 연기하고 unsafe (또는 const 가 아님)를 위반하도록 제안합니다. 하지만 우리는 실제로 참조 투명성을 보장하지 않으므로 사람들이 그것을 가정할 수도 없습니다.

나중에 경험을 쌓았을 때 결정을 내릴 수 있습니다.
경험을 얻는 것에는 사람들이 비결정론을 활용하려 하지만 실패하고, 이를 보고하고 그들의 사용 사례에 대해 알려주는 것이 포함됩니다.

예, 하지만 그것은 const 평가가 아닙니다.

const에서 int를 ptr로 변환하는 것은 큰 손실처럼 보이지 않습니다. 필드 오프셋을 얻는 것이 더 중요해 보이며 그것이 제가 보존하려고 하는 것입니다.

@SoniEx2 함수에 const 를 추가할 때 동작을 자동으로 변경하고 싶지 않으며 이것이 본질적으로 귀하의 제안이 수행하는 작업입니다.

@centril 동의합니다. 이제 보수적인 일을 합시다. 그래서 우리는 이것들을 안전하지 않게 만들지 않고 불안정하게 만듭니다. 이런 식으로 libstd가 사용할 수 있지만 세부 사항은 나중에 결정할 수 있습니다.

우리가 가지고 있는 한 가지 문제는 사용자가 항상 통합을 도입하고 멋진 변환을 수행하여 수행하는 모든 분석을 벽돌로 만들 수 있다는 것입니다. 따라서 이러한 우회 변환을 UB로 만들어 나중에 변경할 수 있도록 해야 합니다.

런타임에도 여전히 동일할 것이고, const는 const 시간에만 변경합니다. 이는... const 없이도 할 수 없습니다.

const fns가 다른 포인터 앨리어싱 규칙을 가진 하위 언어가 되는 것은 괜찮습니다.

@Centril @est31 클로로 트리플루오로에틸렌이 무엇과 관련이 있는지 잘 모르겠습니다.

@sgrif https://en.wikipedia.org/wiki/Compile_time_function_execution

@sgrif CTFE(컴파일 시간 함수 평가)는 오랫동안 Rust에 사용되었습니다(이 스레드의 오래된 부분 포함). 이미 중심 어딘가에 정의되어야 하는 용어 중 하나입니다.

@sgrif lol 대부분 죄송합니다 저는 "지금 어떤 이상한 단어를 사용하고 있습니까?"라고 궁금해하는 사람입니다. IRC에서 @eddyb 가 "CTFE"를 언급했을 때 나는 그에게 그것이 무엇을 의미하는지 물어야 했다고 생각합니다.p.

이 페이지의 @eddyb ctrl+f + CTFE는 이를 정의하는 것으로 이어지지 않습니다. 어느 쪽이든, 나는 우리가 사람들에게 여기 토론에 참여하기 위해 많은 조사를 하도록 강요하고 싶지 않다는 가정 하에 주로 진행하고 있습니다. "이것이 의미하는 바를 이미 알고 있어야 합니다"는 상당히 배제적인 IMO입니다.

@Centril @est31 감사합니다 :heart:

그래서...에 대한 어떤 생각

우리가 가지고 있는 한 가지 문제는 사용자가 항상 통합을 도입하고 멋진 변환을 수행하여 수행하는 모든 분석을 벽돌로 만들 수 있다는 것입니다. 따라서 이러한 우회 변환을 UB로 만들어 나중에 변경할 수 있도록 해야 합니다.

따라서 const fn 내부의 공용체 필드 액세스도 불안정해야 합니까?

이 페이지의 ctrl+f + CTFE는 이를 정의하는 것으로 이어지지 않습니다.

죄송합니다. 제가 의미하는 바는 Rust의 디자인 및 개발에서 이 1.0 이전 문제보다 먼저 사용되었다는 것입니다.
이러한 용어에 대한 중심 문서가 있어야 하지만 슬프게도 참조의 용어집 이 정말 부족합니다.
HRTB 및 NLL은 더 최신이지만 인라인으로 설명되지 않는 다른 약어의 두 가지 예입니다.

나는 어떤 토론도 배제되는 것을 원하지 않지만 @Centril 이나 @est31 에게 CTFE를 정의하도록 요청하는 것은 공평하지 않다고 생각합니다. 둘 다 애초에 두문자어를 도입 하지 않았기 때문입니다.
슬프게도 GitHub에서 반드시 작동하지 않는 솔루션이 있습니다. 특정 하위 레딧에서 본 적이 있습니다. 봇이 최상위 주석을 작성하고 일반적으로 사용되는 모든 약어에 대한 확장 목록과 함께 업데이트된 상태로 유지합니다 . 토론에 표시되는 하위 레딧.

또한 CTFE에 대한 두 개의 위키피디아 기사("클로로트리플루오로에틸렌" 및 "컴파일 시간 함수 실행")가 처음 두 개의 결과이기 때문에 내가 Google 버블에 있는지 궁금합니다. 그래도 전자는 "컴파일러 기능에 대해서는 컴파일 타임 함수 실행을 참조하십시오."로 시작합니다.

( 맨 위에 CTFE 위키 링크를 넣었습니다. 이제 const fn s로 돌아갈 수 있습니까? :P)

누군가가 Rustc 가이드 용어집에 CTFE를 추가할 수 있습니까(저는 모바일입니다)?

또한 최소값을 안정화하고 사람들이 실제로 많이 부딪히는 것을 확인해야 한다고 생각합니다. const if 및 match 식을 사용하여 현재 접근 방식으로 보내는 것입니다.

@센트릴

동일한 인수가 주어진 런타임 또는 컴파일 타임에 실행되는 경우 실행 결과가 const fn에 대해 다를 수 있다는 이 놀라운 동작을 문서화해야 하는 사람이 부럽지 않습니다.

위에서 작성한 even 는 포인터의 비트를 검사하기 때문에 CTFE 시간에 실행하면 실패합니다. (실제로 우리는 이것이 심지어 정렬 때문이라고 결정론적으로 말할 수 있지만, 균일성 테스트가 비트 연산을 통해 수행된다면 "full miri"가 적절하게 수행할 것입니다. 그러나 전체 최하위 바이트를 테스트한다고 가정해 봅시다. 마지막 비트.)
여기서 말하는 경우는 컴파일 타임에는 인터프리터 오류로 오류 가 발생하지만 런타임에는 성공하는 함수입니다. 차이점은 함수가 실행을 완료하는지 여부입니다. 나는 그것이 설명하기 어렵다고 생각하지 않는다.

CTFE가 결과로 성공하면 함수의 런타임 버전도 동일한 결과로 성공하도록 보장되어야 한다는 데 동의합니다. 그러나 그것은 우리가 여기서 말하는 것보다 훨씬 약한 보증입니다. 그렇지 않습니까?

@oli-obk

동의합니다. 이제 보수적인 일을 합시다. 그래서 우리는 이것들을 안전하지 않게 만들지 않고 불안정하게 만듭니다. 이런 식으로 libstd가 사용할 수 있지만 세부 사항은 나중에 결정할 수 있습니다.

맥락을 잃었습니다. 여기서 "이것들"은 무엇입니까?

현재 운 좋게도 CTFE 미리는 산술, 비교, 모든 오류와 같은 포인터 값에 대한 작업을 완전히 거부합니다. 이것은 계산에 실제로 사용된 값을 기반으로 CTFE 시간에 수행된 검사이며, 합집합으로 우회할 수 없으며 어쨌든 산술/비교를 수행하는 데 필요한 코드 가 존재하지 않습니다 . 따라서 위에서 언급한 보증을 충족한다고 확신합니다.

CTFE가 포인터 값을 반환하도록 하면 문제를 상상할 수 있지만 컴파일 시간에 계산된 포인터 값이 어디에서나 의미가 있을까요? 우리는 이미 비트로 변환해야 하기 때문에 포인터 값을 포함하지 않도록 계산하는 모든 것을 이미 확인했다고 가정합니다.

우리는 조심스럽게 CTFE miri에 연산을 추가할 수 있으며, 사실 @eddyb 의 offset_of [1]에 필요한 것은 포인터 빼기입니다. 그 코드는 "full miri"에 존재하며 두 포인터가 동일한 할당 내에 있는 경우에만 성공합니다. 이는 위의 보증을 유지하기에 충분합니다. 작동하지 않는 것은 @eddyb 가 보호 장치로 추가한 assert 입니다.
작업이 포인터의 정렬된 부분에만 영향을 미치는 경우 포인터 값에 대한 비트 작업을 허용할 수도 있습니다. 여전히 결정적이며 코드가 실제로 "전체 미리"에 존재합니다.

편집: [1] 참고로, 이 스레드 에서 주제에서 벗어난 것으로 표시되어 링크할 수 없는 그의 매크로를 참조하므로 여기에 사본이 있습니다.

macro_rules! offset_of {
    ($Struct:path, $field:ident) => ({
        // Using a separate function to minimize unhygienic hazards
        // (e.g. unsafety of #[repr(packed)] field borrows).
        // Uncomment `const` when `const fn`s can juggle pointers.
        /*const*/ fn offset() -> usize {
            let u = $crate::mem::MaybeUninit::<$Struct>::uninit();
            // Use pattern-matching to avoid accidentally going through Deref.
            let &$Struct { $field: ref f, .. } = unsafe { &*u.as_ptr() };
            let o = (f as *const _ as usize).wrapping_sub(&u as *const _ as usize);
            // Triple check that we are within `u` still.
            assert!((0..=$crate::mem::size_of_val(&u)).contains(&o));
            o
        }
        offset()
    })
}

EDIT2: 사실, 그는 또한 그것을 여기 에 게시했습니다.

"이것들"은 float -> 비트 변환 및 포인터 -> 변환 사용입니다.

CTFE가 결과로 성공하면 함수의 런타임 버전도 동일한 결과로 성공하도록 보장되어야 한다는 데 동의합니다. 그러나 그것은 우리가 여기서 말하는 것보다 훨씬 약한 보증입니다. 그렇지 않습니까?

따라서 런타임에 인수를 사용하여 호출된 함수는 동일한 인수를 사용하여 컴파일 시간에 평가되는 경우 실제로 종료되는 경우에만 순도가 보장됩니까?

그렇게 하면 우리의 삶이 백만 배 더 쉬워질 것입니다. 특히 허점을 남기거나 획기적인 방식으로 const fn을 손상시키지 않고 비결정론을 방지할 방법이 없기 때문입니다.

따라서 런타임에 인수를 사용하여 호출된 함수는 동일한 인수를 사용하여 컴파일 시간에 평가되는 경우 실제로 종료되는 경우에만 순도가 보장됩니까?

예, 그것이 제가 제안하는 것입니다.

좀 더 생각해보면(그리고 이 글을 쓰는 동안 @oli- obk 의 답장을 읽으면서) "안전한 const fn 는 다음에서 오류가 발생하지 않을 것입니다. 유효한 인수와 함께 호출될 때 CTFE 시간(패닉 제외)". 일종의 "const 안전" 보장. 런타임 동작과 일치하는 성공적인 CTFE에 대해 위에서 언급한 보장과 함께 안전한 const fn 가 성공적인 CTFE 실행과 일치하기 때문에 런타임에 결정적이라는 보장을 제공합니다.

나는 그것이 얻기 어려운 보증이라는 데 동의합니다. 좋든 나쁘든 Rust는 CTFE miri가 결정론을 유지하면서 항상 성공적으로 실행한다고 보장할 수 없는 다양한 안전한 연산을 가지고 있습니다. 예를 들어 @Centril 의 oracle 변종은 최하위 바이트가 0인지 테스트합니다. 관점에서 이 설정에서 CTFE의 "유효한 값 usize "은 PrimVal::Bytes 인 값만 구성하는 반면 PrimVal::Ptr 는 허용되지 않아야 합니다[1]. const 컨텍스트에서 약간 다른 유형 시스템이 있는 것과 같습니다. 저는 miri가 하는 일을 변경할 것을 제안하는 것이 아니라 const fn 에 첨부될 때 다양한 Rust 유형이 "의미"하는 것을 변경할 것을 제안합니다. 이러한 유형 시스템은 CTFE에서 모든 안전한 산술 및 비트 연산이 잘못될 수 없도록 보장합니다. CTFE 유효 입력의 경우 양쪽이 PrimVal::Bytes 이므로 CTFE에서 정수 빼기가 실패할 수 없습니다. 물론, ptr-to-int는 반환 값의 유형이 usize 이지만 CTFE 유효 usize 가 아니기 때문에 이 설정에서 안전하지 않은 작업이어야 합니다.

이것이 우리가 신경을 쓰는 보증이라면 CTFE 기능을 확인할 때 유형 시스템을 더 엄격하게 만드는 것이 무리가 아닌 것 같습니다. 결국, 우리는 더 많은 일을 하기 위해 그것을 사용하기를 원합니다("const 안전" 확인). unsafe const 컨텍스트에서 const 컨텍스트가 추가 보장.

우리의 일반적인 "런타임 안전"이 안전하지 않은 코드에 의해 전복될 수 있는 것처럼 "const 안전"도 전복될 수 있으며 괜찮습니다. 나는 안전하지 않은 코드가 여전히 공용체를 통해 ptr-to-int 캐스트를 수행할 수 있다는 문제를 보지 못했습니다. 결국 안전하지 않은 코드 입니다. 이 세상에서 const 컨텍스트의 안전하지 않은 코드에 대한 증명 의무는 비 const 컨텍스트의 것보다 더 강력합니다. 함수가 정수를 반환하면 이것이 항상 PrimVal::Bytes 이고 PrimVal::Ptr 가 아님을 증명해야 합니다.

@eddyb 의 매크로에는 안전하지 않은 블록이 필요하지만 이러한 "const unsafe 기능"(ptr-to-usize 후 결과 빼기 또는 포인터 빼기 내장 함수 사용)만 사용하기 때문에 여전히 사용하는 것이 안전합니다. 직접) CTFE 오류가 발생하지 않도록 보장하는 방식으로.

이러한 시스템의 비용은 안전한 고차 const fn 가 const fn 클로저를 가져와야 클로저 실행 자체가 "const 안전"을 위반하지 않는다는 것을 보장할 수 있다는 것입니다. 이것이 실제로 안전한 const fn 에 대한 적절한 보증을 얻는 대가입니다.

[1] 비결정론이 어디에서 발생하는지 잘 모르기 때문에 여기에서 float를 완전히 무시합니다. CTFE 시간과 런타임에 다르게 동작하는 부동 소수점 코드에 대한 예를 누군가 제공할 수 있습니까? 예를 들어 부동 소수점 연산을 수행할 때 피연산자 중 하나가 신호 NaN(첫 번째 보증을 얻기 위해 이전 게시물에서 가져온 것)인 경우 miri 오류를 내보내고 CTFE 유형 시스템이 f32 / f64 유형에서 NaN 신호를 허용하지 않습니까("const 안전"을 얻기 위해)?

작동하지 않는 것은 @eddyb 가 보호 장치로 추가한 주장입니다.

물론입니다. 하지만 지금은 assert!(condition); 를 [()][!condition as usize]; 로 다시 쓸 수 있습니다.

물론 다시 작성할 수 있습니다. assert!(condition); [()][!조건을 사용]으로; 지금은.

그것은 내가 생각한 주장이 아니라 귀하의 조건에서 포인터 평등 테스트입니다. 포인터 평등은 악이며 CTFE에서 허용하지 않는 것이 좋습니다.

편집: 신경 쓰지 마세요. 방금 assert 이 오프셋을 테스트한다는 것을 깨달았습니다. 따라서 wrapping_sub 를 수행할 때 포인터가 동일한 블록에 있지 않으면 miri가 오류를 발생하기 때문에 실제로 CTFE 시간에 실패할 수 없습니다.

// guess we can't have this as const fn
fn is_eq<T>(a: &T, b: &T) -> bool {
    a as *const _ == b as *const _
}

전에 말했듯이 실제 포인터가 아닌 미리에서 가상 포인터를 사용하십시오. const 시간에 const 결정성을 제공할 수 있습니다. 함수가 올바르게 작성되면 런타임과 컴파일 시간 동작은 런타임이 비결정적이지만 컴파일 시간이 결정적인지 여부에 관계없이 동일한 결과를 생성해야 합니다. 코드를 작성하면 비결정적 환경에서 결정적 동작을 할 수 있습니다.

필드 오프셋을 얻는 것은 결정적입니다. 가상 포인터를 사용하면 결정적으로 유지됩니다. 실제 포인터를 사용하면 여전히 결정적입니다.

포인터의 14번째 비트의 짝수를 얻는 것은 결정적이지 않습니다. 가상 포인터를 사용하면 결정적이 됩니다. 실제 포인터를 사용하면 결정적이지 않습니다. 하나는 컴파일 타임(결정적 환경)에 발생하고 다른 하나는 런타임(비결정적 환경)에 발생하기 때문에 괜찮습니다.

const fn은 사용 중인 환경만큼 결정적이어야 합니다.

@SoniEx2

// guess we can't have this as const fn

실제로 우리는 할 수 없습니다. 두 포인터 중 하나가 할당된 개체 내에 있다는 의미에서 현재 역참조할 수 없는 경우 오류가 발생하는 원시 포인터 비교 버전으로 살 수 있다고 생각합니다(그러나 "전체 미리"가 현재 구현하는 것은 아님). 그러나 T 의 크기가 0이면 안전한 코드만 고려하더라도 객체의 끝을 지나 하나를 가리킬 수 있기 때문에 is_eq 는 "const safe"가 아닙니다.

C++에서는 끝을 지나 한 포인터를 비교하여 불확실한(비결정적) 결과를 산출할 수 있습니다. C와 C++ 모두 댕글링 포인터를 비교하여 불확실한 결과를 산출할 수 있습니다. LLVM이 무엇을 보장하는지 명확하지 않지만 C/C++에 대해 보장해야 하는 것(둘 중 더 약한 경우)을 초과하는 보장에 내기를 걸지는 않습니다. 이것은 CTFE에서 성공적으로 실행되는 모든 것에 대한 런타임 결정성을 보장하려는 경우 문제입니다.

@RalfJung

차이점은 함수가 실행을 완료하는지 여부입니다.

악마 옹호자: "반환 ⊥" 은 한 경우에 다른 결과를 갖는 것과 같습니다.

나는 그것이 설명하기 어렵다고 생각하지 않는다.

개인적으로 나는 그것을 놀라운 행동으로 봅니다. 설명을 해주시면 이해가 되겠지만(대표는 아니지만...) 제 직감에는 맞지 않습니다.

@oli-obk

따라서 런타임에 인수를 사용하여 호출된 함수는 동일한 인수를 사용하여 컴파일 시간에 평가되는 경우 실제로 종료되는 경우에만 순도가 보장됩니까?

개인적으로 이 보증이 충분하지 않다고 생각합니다. 나는 우리가 순도를 가지고 어디까지 갈 수 있는지 먼저 봐야 한다고 생각합니다. 우리는 그것이 실제로 마비되고 있다는 것을 알았을 때만 더 약한 보증으로 나아가야 한다고 생각합니다.

@RalfJung

이는 안전한 const fn이 성공적인 CTFE 실행과 일치하기 때문에 런타임에 결정적임을 보장합니다.

좋아요; 당신은 나를 잃었다; 두 전제가 주어지면 이 "safe const fn is deterministic" 보장에 어떻게 도달했는지 알 수 없습니다. 그 이유를 자세히 설명해 주시겠습니까?

이것이 우리가 신경을 쓰는 보증이라면 CTFE 기능을 확인할 때 유형 시스템을 더 엄격하게 만드는 것이 무리가 아닌 것 같습니다. 결국, 우리는 더 많은 일을 하기 위해 그것을 사용하기를 원합니다("const 안전" 확인). 그렇다면 const 컨텍스트가 추가 보장을 하기 때문에 이것이 필요하다고 주장하면서 ptr-to-int 캐스트를 const 컨텍스트에서 안전하지 않다고 선언하는 것이 매우 합리적이라고 생각합니다.

우리의 일반적인 "런타임 안전"이 안전하지 않은 코드에 의해 전복될 수 있는 것처럼 "const 안전"도 전복될 수 있으며 괜찮습니다. 나는 안전하지 않은 코드가 여전히 공용체를 통해 ptr-to-int 캐스트를 수행할 수 있다는 문제를 보지 못했습니다. 결국 안전하지 않은 코드입니다. 이 세상에서 const 컨텍스트의 안전하지 않은 코드에 대한 증명 의무는 비 const 컨텍스트의 것보다 더 강력합니다. 함수가 정수를 반환하는 경우 이것이 항상 PrimVal::Bytes 이고 PrimVal::Ptr 가 아님을 증명해야 합니다.

이 단락은 내 귀에 음악입니다! ❤️ 이것은 결정론("순도")을 보장하는 것 같습니까? 그리고 그것은 정확히 내가 이전에 염두에 두었던 것입니다. 나는 const 안전 도 훌륭한 용어라고 생각합니다!

나중에 참조할 수 있도록 이 보증을 "CTFE 건전성"이라고 부르겠습니다. CTFE에 오류가 없으면 동작이 런타임과 일치합니다. 둘 다 발산하거나 둘 다 동일한 값으로 종료됩니다. (여기서 고차 반환 값을 완전히 무시합니다.)

@센트릴

악마 옹호자: "반환 ⊥"은 한 경우에 다른 결과를 갖는 것과 같습니다.

글쎄요, 그것은 분명히 정의의 문제입니다. 내가 설명하는 CTFE 건전성 보증을 이해하고 이것이 우리가 원하는 보증이라는 데 동의한다고 생각합니다. 그것이 우리 가 원하는 전부인지는 토론의 대상입니다 :)

좋아요; 당신은 나를 잃었다; 두 전제가 주어지면 이 "safe const fn is deterministic" 보장에 어떻게 도달했는지 알 수 없습니다. 그 이유를 자세히 설명해 주시겠습니까?

foo(x) 에 대한 호출이 있다고 가정해 보겠습니다. 여기서 foo 는 안전한 const 함수이고 x 는 const-valid 값입니다(즉, &y as *const _ as usize 가 아닙니다. ). 그러면 우리는 foo(x) 가 const 안전에 의해 오류를 발생시키지 않고 CTFE에서 실행된다는 것을 압니다. 결과적으로 CTFE 건전성에 의해 런타임에 foo(x) 는 CTFE에서와 동일한 방식으로 작동합니다.

본질적으로 저는 귀하의 보증을 두 부분으로 분해했다고 생각합니다. 하나는 안전한 const fn이 CTFE가 지원하지 않는 작업을 시도하지 않도록 하는 것입니다(예: stdin에서 읽기 또는 포인터의 최하위 바이트가 0인지 확인). CTFE 가 지원하는 모든 것이 런타임과 일치하는지 확인하는 것입니다.

이 단락은 내 귀에 음악입니다! 마음 이것은 결정론("순수함")을 보장하는 것 같습니까? 그리고 그것은 정확히 내가 이전에 염두에 두었던 것입니다. 나는 const 안전도 훌륭한 용어라고 생각합니다!

마음에 드신다니 다행입니다. :) 이것은 우리가 여기서 말하는 것을 마침내 이해했다는 것을 의미합니다. "순수함"은 너무 많은 다른 것을 의미할 수 있어서, 그 용어가 사용될 때 종종 약간 불안함을 느낍니다. 그리고 결정론은 const 안전을 위한 충분 조건이 아니며 관련 기준은 CTFE에서 실행 시 오류가 발생하는지 여부입니다. (deterministc non-const-safe 함수의 한 가지 예는 orcale 에 0을 곱한 내 변형입니다. 포인터의 바이트를 검사할 때 미리가 오류가 발생하므로 안전하지 않은 코드를 사용하는 경우에도 이 작업을 수행하는 것은 좋지 않습니다. 바이트가 궁극적으로 중요하지 않더라도 포인터의 최하위 바이트를 추출하는 작업이 "const-UB"이므로 안전하지 않은 const 코드에서도 허용되지 않는 것과 같습니다.)

예, 배열 요소의 끝을 지나는 포인터는 아마도 다음 배열 요소를 가리킬 것입니다. 그래서 뭐? 정말 비결정적 아닌가요? 어쨌든 컴파일 타임에 결정적인 것이 중요합니다. 내가 걱정하는 한 런타임 평가는 스택 고갈로 인해 segfault가 될 수 있습니다.

@RalfJung

그러한 시스템의 비용은 안전한 고차 const fn 가 클로저 실행 자체가 "const 안전"을 위반하지 않는다는 것을 보장할 수 있도록 const fn 클로저를 취해야 한다는 것입니다. 이것이 실제로 안전한 const fn 에 대한 적절한 보증을 얻는 대가입니다.

?const 를 도입하여 대부분의 기존 코드 변환을 지원하기 위해 이것이 const ?const fn(T) -> U 바인딩될 수 있는 고차 함수를 작성할 수 있다고 생각합니다. is_const(x : T) ; 그래서 당신은 가지고 있습니다 :

?const fn twice(fun: ?const fn(u8) -> u8) { fun(fun(42)) }

fn id_impure(x: u8) -> u8 { x }
const fn id_const(x: u8) -> u8 { x }
?const fn id_maybe_const(x: u8) -> u8 { x }

fn main() {
    let a = twice(id_impure); // OK!
    const b = twice(id_impure); // ERR!
    let c = twice(id_const); // OK!
    const d = twice(id_const); // OK!
    let e = twice(id_maybe_const); // OK!
    const f = twice(id_maybe_const); // OK!
}

일주일 정도 후에 이 효과(및 그 이상)에 대해 제안하는 RFC를 작성할 것입니다.

@Centril 은 이 시점에서 효과 다형성을 사용하여 효과 시스템을 개발하고 있습니다. 그것이 항상 당신의 비밀(?) 의제였다는 것을 알고 있습니다.

@RalfJung 작년에 https://github.com/rust-lang/rfcs/pull/2237에서 이미 비밀을 공개했지만 다시 작성해야 할 것입니다 ;)
이제 거의 공개 도메인 ^,-

@SoniEx2

예, 배열 요소의 끝을 지나는 포인터는 아마도 다음 배열 요소를 가리킬 것입니다. 그래서 뭐? 정말 비결정적 아닌가요? 어쨌든 컴파일 타임에 결정적인 것이 중요합니다. 내가 걱정하는 한 런타임 평가는 스택 고갈로 인해 segfault가 될 수 있습니다.

문제는 다음과 같은 상황에서 발생합니다(C++에서).

int x[2];
int y; // let's assume y is put right after the end of x in the stack frame
if (&x[0] + 2 == &y) {
  // ...
}

C 컴파일러는 false 에 대한 비교를 최적화하기를 원합니다. 결국 하나의 포인터는 x 를 가리키고 다른 하나는 y 를 가리키므로 두 포인터가 같을 수는 없습니다.
물론, 하나의 포인터가 x 의 끝을 가리키고 $#$5 y #$ 와 같은 주소인 머신에서 주소 가 동일하다는 점은 제외합니다! 따라서 컴파일러가 주소의 출처를 더 이상 볼 수 없도록 코드를 충분히 가리면 비교가 true 로 평가된다는 것을 알 수 있습니다. 따라서 C++ 표준은 최적화( false 라고 함)와 어셈블리로 컴파일( true 라고 함)을 모두 정당화하여 두 결과가 모두 비결정적으로 발생하도록 허용합니다. C 표준은 이를 허용하지 않으므로 LLVM(및 GCC) 비준수 컴파일러는 둘 다 이러한 종류의 최적화를 수행하기 때문입니다.

나는 이 스레드 및/또는 IRC에 대한 관련 토론에서 나온 const 안전, const 건전성 등에 대한 내 아이디어의 요약을 작성했습니다. https://www.ralfj.de/blog/2018/07/19/ const.html

여기에서 이 문제는 너무 많은 것들이 논의되었기 때문에 풀기 다소 어려워졌습니다. @oli-obk는 const-eval 문제에 대한 리포지토리를 유용하게 만들었습니다. 따라서 특정 하위 문제를 논의하기에 좋은 장소는 아마도 https://github.com/rust-rfcs/const-eval의 문제 추적기일 것입니다.

@Centril 은 향후 확장과 호환되는 최소 버전을 안정화할 것을 제안했습니다.

• 특성 경계가 있는 일반 인수 없음
• fn 포인터 또는 dyn Trait 유형의 인수 또는 반환 유형 없음
  
  
  
  • 인수 유형에 대해 재귀적으로 검사하므로 인수 필드도 이러한 유형이 아닐 수 있습니다.
  
  
• 안전하지 않은 코드 없음(문제가 되는 항목이 있는지 여부를 모르기 때문에)
  
  
  
  • 저는 개인적으로 이미 추가 기능 게이트 뒤에 있는 union 와 원시 포인터 derefs(일반적으로 현재 상수에서 금지됨)를 제외하고는 괜찮다고 생각합니다. 다른 모든 안전하지 않은 코드는 다른 안전하지 않은 const fns 또는 const 내장 함수를 거쳐야 하며, 이는 자체 토론 wrt 안정화가 필요합니다.
  
  

(nit: 내 제안에는 fn 포인터 또는 $#$ const fn 반환 유형에 대한 dyn Trait 에 대한 재귀 검사도 포함되었습니다.)

특성 경계가 있는 일반 인수 없음

명확히 하자면, 이와 같은 것이 받아들여질 것인가 말 것인가?

struct Mutex<T> where T: Send { /* .. */ }

impl<T> Mutex<T> where T: Send {
    pub const fn new(val: T) -> Self { /* .. */ }
}

경계는 const fn 자체의 일부가 아닙니다.

또한 명확히 하기 위해: 이러한 것들을 안정화하고 나머지는 기능 게이트 뒤에 남겨두는 제안이 아니면 그것들을 안정화하고 나머지를 모두 오류로 만들려는 제안입니까?

@mark-im 나머지는 기능 게이트 뒤에 남습니다.

@oli-obk 안전하지 않은 코드의 문제는 무엇입니까? 모두 동일한 문제가 있는 const X : Ty = ... 에서 unsafe 를 허용합니다. const fn 바디는 const 바디와 동일하게 확인되어야 한다고 생각합니다.

나는 우리가 "unconst" 작업에 대해 보수적으로 유지하기를 원한다고 생각합니다. 즉, 안전하지만 const-safe하지 않은 작업(기본적으로 원시 포인터에 대한 모든 것)이지만 이러한 작업은 이미 const 컨텍스트에서 완전히 허용되지 않습니다. 맞습니까?

경계는 const fn 자체의 일부가 아닙니다.

아니요, 해당 제안에서는 impl 블록의 경계도 허용되지 않습니다.

안전하지 않은 코드의 문제는 무엇입니까?

내 의견에 언급 된대로 문제가 보이지 않습니다. 모든 const 안전하지 않은 기능/기능은 어쨌든 자체 안정화를 거쳐야 합니다.

@RalfJung 내 생각에 문제는 " @Centril 은 우리가 뭔가를 놓친 것에 대해 긴장하고 있습니다. 그것들은 이미 const 컨텍스트에서 완전히 허용되지 않습니다"입니다. ;) 하지만 어떤 시점에서 unsafe { .. } in const fn 를 안정화해야 하므로 문제가 없고 모든 unconst 작업을 포착했다고 확신하면 실행해 볼까요?

게다가, 우리가 뭔가를 놓쳤다면, 사람들이 const 에서 그것을 사용할 수 있기 때문에 우리는 이미 망했습니다.

나는 여전히 const fn RFC repo 의 const 안전/승진 부분을 채우는 PR을 작성할 계획입니다. 우리가 모든 것을 다루었는지(그리고 테스트 케이스가 있는지) 주의 깊게 확인해야 할 때입니다.

Discord에 나온 또 다른 사항은 FP 작업입니다. 현재로서는 실제 하드웨어와 일치한다고 보장할 수 없습니다. CTFE는 IEEE를 정확히 따르지만 LLVM/하드웨어는 그렇지 않을 수 있습니다.

이는 const 항목에도 적용되지만 런타임에 실행되지 않는 항목입니다. 반면 const fn 는 그럴 수 있습니다. 따라서 const fn 에서 FP 작업을 안정화하지 않는 것이 현명해 보입니다.

OTOH, 우리는 이미 FP 작업의 결과를 홍보합니까? 그래서 우리는 이미 stable에서 관찰 가능한 런타임/컴파일 시간 불일치를 가지고 있습니다. 우리가 그것을 취소할 수 있는지 확인하기 위해 분화구를 실행할 가치가 있습니까?

나중에 참조할 수 있도록 다음 문서는 부동 소수점 및 결정론과 관련이 있습니다.

• https://gafferongames.com/post/floating_point_determinism/

@RalfJung

우리가 그것을 취소할 수 있는지 확인하기 위해 분화구를 실행할 가치가 있습니까?

우리가 이것을 할 수 있다면 놀라겠지만 적어도 시도해 볼 가치가 있습니다. :)

@RalfJung 이 스레드 https://github.com/rust-lang/rust/issues/24111#issuecomment -386764565에 흥미로운 입력이 있을 수 있습니다.

키워드 형식을 const fn 로 유지하고 싶다고 가정할 때 지금 안정화하는 것은 충분히 제한적이며 꽤 괜찮은 솔루션이라고 생각합니다.

이러한 단편적인 안정화 작업을 수행할 때
제한 사항과 그 정당성에 대한 명확한 목록을 요청하십시오. 이것의
사용자가 겉보기에 무해한 변경을 하고
컴파일 오류가 발생하므로 최소한 오류를 개선할 수 있습니다. 나
추론이 많은 토론에 걸쳐 퍼져 있음을 인식합니다.
나는 따라했지만 문서에 테이블이 있어야한다고 생각합니다 (또는
참조 또는 nomicon, 최소한) 허용되지 않는 각 작업을 나열하고,
발생할 수 있는 문제 및 안정화 가능성(예: "절대",
"RFC XYZ가 구현된 경우", "사양의 이 부분을 확정한 후").

2018년 8월 20일 월요일 오후 1:44 Eduard-Mihai Burtescu <
[email protected]>은 다음과 같이 썼습니다.

키워드 형식을 const fn으로 유지하고 싶다고 가정하면
지금 은 충분히 제한적이며 꽤 괜찮은 솔루션입니다(어떻게
내가 전에 본 적이 없어?!)

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

@est31 @rkruppe 가 이미 썼듯이 이러한 퓨즈는 -ffast-math 없이 작동하는 것이 불법이며 LLVM이 이를 올바르게 처리한다고 생각합니다.

내가 기억하는 바에 따르면 기본 산술은 그다지 문제가 되지 않지만(x87... 때문에 32비트 x86 제외) 초월 함수는 문제가 있습니다. 그리고 그것들은 const fn 가 아닙니까? 그래서 제 희망은 결국 const 항목, 판촉 및 const fn 사이에서도 동등할 수 있기를 바랍니다.

@RalfJung 예를 들어 유출 및 일부 작업 사이에 FPU 레지스터로 다시 로드하면 유출 없이 동일한 계산과 동일한 결과를 얻을 수 있다고 확신하지 못합니다.

내가 기억하는 바에 따르면 기본 산술은 그다지 문제가 되지 않지만(x87... 때문에 32비트 x86 제외) 초월 함수는 문제가 있습니다.

초월 함수는 어떻게 문제를 의미합니까?

IIRC에서 일부 초월 기능은 일반 x86 프로세서에서 지원되지만 이러한 기능은 느리고 피하며 기존 구현과의 완전성과 호환성을 위해서만 포함됩니다. 따라서 거의 모든 곳에서 초월 함수는 기본 산술 함수의 조합으로 표현됩니다. 이것은 산술 함수의 참조 투명도에 차이가 없음을 의미합니다. 기본 기능이 "안전"하다면 초월 기능을 포함하여 그 위에 구축된 모든 것이 안전합니다. 여기서 "참조 불투명성"의 유일한 출처는 이러한 기본 산술 함수의 관점에서 이러한 초월 함수의 서로 다른 근사(구현)일 수 있습니다. 그것이 문제의 근원인가?

@est31 대부분의 초월 함수는 궁극적으로 원시 정수와 부동 소수점 연산으로 구성된 라이브러리 코드일 뿐이지만, 이러한 구현은 표준화되지 않았으며 실제로 Rust 프로그램은 수명 동안 세 가지 다른 구현과 상호 작용할 수 있으며, 그 중 일부는 호스트 또는 대상에 따라 다릅니다. 플랫폼:

• 프로그램이 대상에서 사용하는 런타임 구현이 있습니다(예: 대상 플랫폼 libm 또는 경우에 따라 하드웨어 명령).
• LLVM이 사용하는 일정한 폴더가 있습니다(분명히 이것은 호스트 플랫폼 C libm일 뿐입니다).
• MIRI는 이러한 작업으로 무엇이든 할 수 있습니다(예: rustc_apfloat 또는 https://github.com/japaric/libm/과 같은 Rust 구현 해석).

이 중 하나라도 서로 일치하지 않으면 표현식이 평가되는 시점에 따라 다른 결과를 얻을 수 있습니다.

@rfcbot 취소

우리는 가까운 장래에 전체 monty를 안정화할 것 같지 않습니다.
대신, 가까운 시일 내에 안정화될 수 있는 보다 최소한의 하위 집합(https://github.com/rust-lang/rust/issues/24111#issuecomment-414310119에 대략적으로 설명됨)에 대한 합의를 발전시키고 싶습니다. .
이 하위 집합은 #53555에서 추적됩니다. 자세한 설명은 거기에서 볼 수 있습니다.

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

@rkruppe 초월 함수를 llvm 내장 함수로 낮추는 이유가 있습니까? 우리가 제어하고 모든 플랫폼에서 동일하게 잘 알려진 녹 전용 구현으로 낮추어 전체 문제를 피할 수는 없습니까?

초월 함수를 llvm 내장 함수로 낮추는 이유가 있습니까?

전체 크로스 플랫폼 libm을 구현하지 않는 단순성 외에도 내장 함수는 LLVM의 최적화 프로그램과 코드 생성에서 일반 라이브러리 함수가 얻을 수 없는 이점이 있습니다. 분명히 일정한 접기(& 값 범위 분석과 같은 관련 항목)는 이 컨텍스트에서 문제이지만 그렇지 않으면 매우 유용합니다. 대수적 ID도 있습니다(SimplifyLibCalls 패스에 의해 적용됨). 마지막으로, 몇 가지 함수(대부분 sqrt와 그 상호, 초월적이지는 않지만 무엇이든 간에)에는 SSE를 사용하여 x86에서 sqrtss 를 생성하는 특수 코드 생성 지원이 있습니다.

우리가 제어하고 모든 플랫폼에서 동일하게 잘 알려진 녹 전용 구현으로 낮추어 전체 문제를 피할 수는 없습니까?

위의 모든 사항을 무시하더라도 IMO는 좋은 옵션이 아닙니다. 대상 플랫폼에 C libm이 있는 경우 더 최적화되었거나 팽창을 피하기 위해 사용할 수 있어야 합니다.

내장 함수는 LLVM의 옵티마이저와 코드젠에서 일반 라이브러리 함수가 얻을 수 없는 이점이 있습니다.

빠른 수학이 켜져 있는 경우에만 이러한 최적화가 활성화된다고 생각했습니다.

대상 플랫폼에 C libm이 있는 경우 더 최적화되었거나 팽창을 피하기 위해 사용할 수 있어야 합니다.

확신하는. 컴파일된 바이너리 또는 더 작은 바이너리의 속도 향상과 같은 문제를 위해 이 다소 학문적인 속성(참조 투명성)을 교환할 수 있는 옵션 이 항상 있어야 합니다. 예를 들어 libm 플랫폼을 사용하거나 빠른 수학 모드를 켭니다. 아니면 영원히 빠른 수학 모드를 허용하지 않아야 한다고 제안하십니까?

IMO 우리는 const 컨텍스트에서 f32::sin() 를 허용하지 않아야 합니다. 적어도 + , - 등을 허용하는 경우에는 허용하지 않아야 합니다. 이러한 금지는 사람들이 상자를 만들고 사용하도록 강제할 것입니다. const 호환 구현을 제공합니다.

빠른 수학이 켜져 있는 경우에만 이러한 최적화가 활성화된다고 생각했습니다.

이러한 함수에 대한 지속적인 평가와 sqrtss 의 방출은 -ffast-math 없이 정당화하기 쉽습니다. 올바르게 반올림할 수 있기 때문입니다.

아니면 영원히 빠른 수학 모드를 허용하지 않아야 한다고 제안하십니까?

나는 아무 것도 제안하지 않으며 그러한 재산이 보장되어야 하는지에 대한 의견(atm)도 없습니다. 나는 단순히 제약 조건을 보고하고 있습니다.

const fn 컨텍스트에서 Vec 로 인한 ICE에 대한 미해결 문제를 찾을 수 없습니다.

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=508238a9f06fd85720307bf6cc227586

이에 대한 새 문제를 열어야 합니까?

@Voultapher 네, 새로운 ICE처럼 보입니다.

알겠습니다. #55063을 열었습니다.

컴파일러가 사용자가 const fn 주석을 달 때 컴파일 타임 constexpr에서 함수를 호출할 수 있는지 여부를 확인할 수 있다면 모든 함수에 대한 검사를 자동으로 수행하지 않는 이유는 무엇입니까? (자동 특성과 유사)? 실제 부정적인 영향은 생각나지 않으며, 오류가 발생하기 쉬운 인간의 판단에 의존할 필요가 없다는 분명한 이점이 있습니다.

주요 단점은 공개 세부 사항이되므로 구현
const가 아닌 기능의 변경이 이제 중단됩니다.

또한 우리는 인간의 판단에 의존할 필요가 없습니다. 주석이 없는 함수가 const fn 일 수 있는 경우를 알려주는 클리피 보풀을 가질 수 있습니다. https://github.com/rust-lang/rust-clippy/issues/2440

이것은 지역 변수의 가변성을 추론하지 않고 대신 컴파일러가 mut 를 추가하거나 제거할 위치를 알려주는 방법과 유사합니다.

@remexre const fn 는 인터페이스 사양으로 작동합니다. 나는 이 기능의 아주 작은 세부 사항에 대해 잘 알지 못하지만(그리고 아마도 여기에 나오는 내용은 이미 생각한 것일 수 있음) 함수가 const 로 잘못 주석 처리된 경우 컴파일러가 알려주는 두 가지 경우는 다음과 같습니다. 이러한 함수가 &mut 를 매개변수로 사용하거나 다른 비 const 함수를 호출하면 컴파일이 실패합니다. 따라서 const fn 의 구현을 변경하고 이러한 제한을 어기면 컴파일러가 중지합니다. 그런 다음 (a) 별도의 기능에서 const 가 아닌 비트를 구현하거나 의도된 변경인 경우 API를 중단하도록 선택할 수 있습니다.

내가 논의한 적이 없는 또 다른 중간 지점이 있으며 명시적으로 설정되지 않은 경우 이 마커의 반대와 일종의 "함수 순도 추론"을 도입할 가능성이 있습니다. 그런 다음 문서는 실제 마커를 표시하지만 const 인 경우 해당 마커의 안정성을 보장하지 않는다는 일종의 경고와 함께 표시됩니다. 문제는 이것이 게으름을 부추기고 거의 매번 이것을 하도록 부추길 수 있다는 것인데, 이는 목적이 아닙니다.

const fn이 출력을 생성할 수 있어야 합니까? &mut 가 허용되지 않는 이유는 무엇입니까?

@aledomu 내 의견은 @AGaussman에게 전달되었습니다. 나는 라이브러리 작성자가 "의도된" const가 아닌 함수를 노출하는 경우에 대해 이야기하고 있습니다. const가 유추된 경우 해당 기능을 const가 아닌 것으로 만드는 것은 획기적인 변경이 될 것입니다.

@SoniEx2 const fn 는 컴파일 타임에 평가할 수 있는 함수로, 이는 모든 순수 함수에서만 발생합니다.

@remexre API의 안정적인 부분이 아닌 경우 표시하지 마십시오.

내가 논평한 추론 비트에 대해, 그것이 내가 크레이트 문서에 대한 몇 가지 경고의 필요성을 언급한 이유입니다.

차이점이 뭐야? 절대 없음!

const fn add_1(x: &mut i32) { x += 1; }
let mut x = 0;
add_1(&mut x);
assert_eq!(x, 1);
x = 0;
add_1(&mut x);
assert_eq!(x, 1);

const fn added_1(x: i32) -> i32 { x + 1 }
let mut x = 0;
x = added_1(x);
assert_eq!(x, 1);
x = 0;
x = added_1(x);
assert_eq!(x, 1);

다음과 같은 대상 문제를 제출했습니다.

• 부동 소수점 + 상수 평가: https://github.com/rust-lang/rust/issues/57241
• 패턴과의 통합: https://github.com/rust-lang/rust/issues/57240

다음과 같은 대상 문제가 이미 존재합니다.

• 패닉: https://github.com/rust-lang/rust/issues/51999
• 루프: https://github.com/rust-lang/rust/issues/52000
• 제어 흐름: https://github.com/rust-lang/rust/issues/49146
• 원시 포인터 비교: https://github.com/rust-lang/rust/issues/53020
• 원시 포인터 역참조: https://github.com/rust-lang/rust/issues/51911
• usize 캐스트에 대한 원시 포인터: https://github.com/rust-lang/rust/issues/51910
• 유니온 필드 액세스: https://github.com/rust-lang/rust/issues/51909
• 장기 실행 평가에 대한 경고: https://github.com/rust-lang/rust/issues/49980
• 오류를 일으키지 않는 지속적인 전파: https://github.com/rust-lang/rust/issues/28238
• &mut T 참조 및 차용: https://github.com/rust-lang/rust/issues/57349

다른 문제에 의해 아직 추적되지 않은 다른 영역이 있는 경우, 그 부분에 대해 논의해야 합니다. const eval 및 const fn , 나는 사람들이 새로운 문제를 만들 것을 제안합니다(그리고 cc me + @oli-obk 포함).

이것으로 이 문제의 유용성을 마치며 이로써 종료됩니다.

모든 세부 사항을 염두에 두지는 않았지만 miri에서 지원하지만 min_const_fn 에서 아직 활성화되지 않은 더 많은 것이 있지 않습니까? 예를 들어 원시 포인터.

@SimonSapin 예, 잘 잡았습니다. 이에 대한 몇 가지 기존 문제가 더 있습니다. 댓글 + 문제 설명을 업데이트했습니다. 다루지 않은 일이 발생하면 새로운 문제를 만드십시오.

메타 추적 문제가 다루는 내용이 보다 구체적인 문제에 의해 철저하게 다루어지는지 전혀 명확하지 않을 때 메타 추적 문제를 종료하는 것은 적절하지 않다고 생각합니다.

Servo에서 #![feature(const_fn)] 를 제거하면 오류 메시지는 다음과 같습니다.

• trait bounds other than `Sized` on const fn parameters are unstable
• function pointers in const fn are unstable

(이 const fn 는 모두 private 필드가 있는 유형에 대한 간단한 생성자입니다. Clone 가 생성자에서 사용되지 않더라도 전자 메시지는 struct Guard<T: Clone + Copy> 의 생성자에 있습니다. 후자는 Option<fn()> (단순화)를 None 또는 Some(name_of_a_function_item) 로 초기화하기 위한 것입니다.)

그러나 이 호의 설명에는 특성이나 함수 포인터 유형이 모두 언급되어 있지 않습니다.

위의 두 가지 특정 문제가 더 있어야 한다는 뜻은 아닙니다. 내 말은 const_fn 기능 게이트 뒤에 있는 모든 항목(여기에서 여전히 오류 메시지가 표시됨)에 추적 문제가 있다는 것을 어떻게든 확인할 때까지 이 항목을 다시 열어야 합니다. 또는 const_fn 이 완전히 안정화될 때까지.

@SimonSapin

메타 추적 문제가 다루는 내용이 보다 구체적인 문제에 의해 철저하게 다루어지는지 전혀 명확하지 않을 때 메타 추적 문제를 종료하는 것은 적절하지 않다고 생각합니다.

이 문제는 https://github.com/rust-lang/rust/issues/34511 의 특징을 가지고 있습니다. 이는 추적 문제가 진행되는 한 가장 큰 혼란 중 하나입니다. 이 문제는 또한 한동안 모두에게 무료였으므로 지금은 메타 문제로 작용하지 않습니다. 이러한 모든 것을 무료로 사용하려면 대신 http://internals.rust-lang.org/ 를 사용하십시오.

그러나 이 호의 설명에는 특성이나 함수 포인터 유형이 모두 언급되어 있지 않습니다.

위의 두 가지 특정 문제가 더 있어야 한다는 뜻은 아닙니다.

그것이 바로 내가 해야 할 일이라고 생각합니다. T-Lang 분류 관점에서 목표가 있고 실행 가능한 문제가 있는 것이 좋습니다.

내 말은 const_fn 기능 게이트 뒤에 있는 모든 항목(여기에서 여전히 오류 메시지가 표시됨)에 추적 문제가 있다는 것을 어떻게든 확인할 때까지 이 항목을 다시 열어야 합니다. 또는 const_fn 이 완전히 안정화될 때까지.

const_fn 기능 게이트가 무엇을 구성하는지 또는 어느 시점에서 모두 안정화될 것인지조차 명확하지 않습니다. 원래 RFC의 범위와 함수 포인터를 제외한 모든 것에는 미해결 문제가 있고 일부는 문제가 있습니다.

const_fn 기능 게이트가 무엇을 구성하는지조차 나에게 명확하지 않습니다.

그것이 바로 우리가 그것을 알아낼 때까지 닫지 말아야 하는 이유입니다, IMO.

모든 것

그래도 그게 정말 전부일까요?

관련: https://github.com/rust-lang/rust/issues/57261

const_string_new 기능에 무슨 일이 일어났는지 아는 사람이 있습니까? 추적 문제가 있습니까? 불안정한 책 은 여기로 연결됩니다.

@phansch 모든 rustc_const_unstable 가 여기를 가리키기 때문입니다. (cc @oli-obk 우리가 고칠 수 있습니까?)

문제는 그때 열려 있어야 합니다. 지적받는건 유저로서 모욕일뿐
닫힌 문제에.

2019년 1월 9일 수요일 04:05 Mazdak Farrokhzad < [email protected]
썼다:

@phansch https://github.com/phansch 그 이유는 모두
여기에 Rustc_const_unstable 지점이 있습니다.

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

@durka : 야간에 무언가가 닫혀 있고 해상도가 여전히 안정적인 상태에 도달하지 않은 가능한 창이 항상 있을 것입니다. 그게 어떻게 모욕적이야?

나는 여기에서 논평하는 것을 거부했고 아마도 이 대화를 내부 스레드로 옮겨야 할 것입니다(이미 하나가 있습니까?) 하지만...

폐쇄 결정은 나에게 의미가 없습니다. 컴파일러의 오류 메시지에 표시되기 때문에 추적 문제이며 혼자가 아닙니다. 이 게시물에서 몇 가지 더 많은 예를 참조하세요. https://internals.rust-lang.org/t/psa-tracking-for-gated -언어 기능/2887. 나에게 이 문제를 닫는 것은 안정성을 의미하지만 아직까지는 그렇지 않습니다.

솔직히 말해서 이것을 닫는 데 대한 논쟁을 볼 수 없습니다 ... 더 목표가 된 문제가 존재하여 기쁩니다. 따라서 희망적으로 새로운 토론과 초점을 가지고 구현을 진행할 수 있지만 컴파일러를 연결하는 명확한 방법이 보이지 않습니다. 그들과의 메시지.

다시 말하지만 내부에 스레드가 필요하거나 이미 있는 경우 이 대화를 거기로 이동할까요?

편집: 아니면 책이 구식이라는 문제입니까? RFC의 예제( #[derive(...)] 몇 개 누락)를 시도하면 Rust rustc 1.31.1에서 오류 없이 작동하는 것 같습니다. 여기를 가리키는 컴파일러 오류 메시지가 여전히 있습니까? 다음과 같은 오류를 링크할 수 있는 위치가 있으면 좋을 것입니다.

error: only int, `bool` and `char` operations are stable in const fn

우리가 그것들을 특정 문제에 연결하고 싶다면 개선될 가능성이 있습니다.

자, 여기 이 문제가 미해결 상태로 남아 있다는 강력한 증거가 있어야 합니다. 내가 말할 수 있는 한:

https://github.com/rust-lang/rust/blob/6ecad338381cc3b8d56e2df22e5971a598eddd6c/src/libsyntax/feature_gate.rs#L194

종료된 문제를 가리키는 유일한 active 기능입니다.

이상적인 세계에서는 이러한 종류의 토론이 실제로 자동화되어야 한다고 생각합니다. 왜냐하면 우리가 발견한 것처럼 사람들은 일이 어떻게 작동해야 하는지에 대해 다양한 의견과 아이디어를 가지고 있기 때문입니다. 그러나 그것은 실제로이 스레드의 대화가 아닙니다 ...

우리가 그것들을 특정 문제에 연결하고 싶다면 개선될 가능성이 있습니다.

예, 이것은 올바른 솔루션이며 @Centril 이 이미 제안한 것입니다.

초기 코멘트는 @ErichDonGubler 가 언급한 "창" 에 도착한 특정 문제로 사람들을 리디렉션하도록 편집되었습니다.

https://github.com/rust-lang/rust/issues/57563 이 이제 나머지 불안정한 const 기능을 추적하기 위해 열렸습니다.

그렇다면 누군가가 여기에서 문제 본문을 편집하여 #57563에 눈에 띄게 링크할 수 있습니까?

@glaebhoerl 완료 :)

안녕하세요, ncurses-rs를 컴파일할 때 error[E0658]: const fn is unstable (see issue #24111) 를 얻었기 때문에 여기에 왔습니다. 어떻게 해야 하나요? 녹을 업그레이드 하시겠습니까? 나는 가지고있다

$ cargo version
cargo 1.27.0
$ rustc --version
rustc 1.27.2

편집: brew uninstall rust 하고 Rustup 설치 지침 을 따랐습니다. 이제 rustc --version 는 rustc 1.33.0 (2aa4c46cf 2019-02-28) 이고 해당 오류는 사라졌습니다.

예, 안정에서 const fn 를 사용할 수 있으려면 컴파일러를 업데이트해야 합니다.