これは＃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は、現在の限定された形式でも便利な機能であることは間違いありませんが、理想的にはこのパスに進む前に、「constfnアプローチ」を支持する人にとって本当に欲しいものです。彼らの好みのエンドゲームについて考え、明確に表現してください...最終的にはC++のconstexprデザイン全体を多かれ少なかれコピーすることになる可能性が非常に高いようです。

それ以上に、私が個人的に望んでいるのは、それをどのように実装するのか、そして言語のどの部分をカバーするのかについて、かなり明確な見解を持っているということです。 とは言うものの、これは私の頭の中では整数に対する関連する定数やジェネリックスのサポートと非常に密接に関連しています。

@eddybと私は最近、非常に幅広いコードの範囲を常に評価できるスキームについてスケッチを行いました。 基本的に、すべての定数をMIRに下げて解釈します（場合によっては、
抽象通訳、まだ評価できないジェネリックがある場合、それが私にとって最も興味深いところです）。

ただし、「組み込み言語」の大部分をサポートするのはかなり簡単なように思えますが、実際のコードは、メモリ割り当てを非常に迅速に行う必要性にぶつかります。 つまり、 Vecまたはその他のコンテナを使用する必要があります。 そして、それはこの通訳スキーム全体が私の心にもっと複雑になり始めるところです。

そうは言っても、 @ glaebhoerl 、あなたがあなたの好みの代替エンドゲームを明確に表現するのを聞いてみたいです。 const fn RFCでそのような考えをスケッチしたと思いますが、この文脈でもう一度聞いてみるとよいと思います。 :)

割り当ての問題は、実行時にエスケープすることです。
どういうわけか、そのコンパイル時/実行時の障壁を越えることを禁止できれば、 const fnでliballocが機能する可能性があると思います。
解釈されたスタック上のバ​​イトアドレス可能な値を処理するよりも、これらの種類の割り当てを管理することは難しくありません。

または、バリアを通過する必要があるたびに値を割り当てて入力するランタイムコードを生成することもできますが、どのようなユースケースがあるかはわかりません。

本格的なconstexprのような評価でも、 const fnは純粋であることに注意してください。 'staticデータで2回実行すると、まったく同じ結果になり、副作用。

@nikomatsakisもし私が持っていたら、それについて言及したでしょう。 :)私は主に既知の未知数を見るだけです。 ジェネリックシステムの一部としてconstを使用することは、もちろん、C++設計であると私が理解したことの一部でした。 constとconstのジェネリックパラメーターを関連付けている限り、タイプの一部としてconstを含む固定サイズの配列がすでにあり、抽象化したいと考えています。それらの場合、単に一般的な方法ではなく、はるかに優れた方法があったとしたら、私は驚きます。 物事のconst fnの部分は、より分離可能で変化しやすいと感じます。 物事をさらに進めて、ジェネリックスにconst implやconst Traitの境界があることを想像するのは簡単ですが、私は、すでに物事を理解しているこの種の一般的なものの先行技術があると確信しています。そしてそれを見つけようとするべきです。

Rust言語の主なユースケースのうち、カーネルのように主に低レベルの制御を必要とするものは、すでに十分に機能しているように見えますが、Rustが多くの可能性を秘めている可能性がある別の領域は、主に高性能を必要とするものです。段階的計算（ const fnはすでに非常に限定されたインスタンスです）に対する（何らかの形での）スペースの強力なサポートは、ゲームチェンジャーになる可能性があるようです。 （ここ数週間で、Rustからより優れたステージング機能を備えた言語に切り替えることを決定した人々による2つの別々のツイートに出くわしました。）言語の既存のソリューションのいずれかが「私たちに近い」かどうかはわかりません- C ++のconstexpr 、DのアドホックCTFE、手続き型マクロ-この種のことに対して、本当に刺激的で強力/完全であると感じます。 （手続き型マクロは持っているのは良いことのように思えますが、抽象化とDSLにはもっと多く、パフォーマンス指向のコード生成にはそれほど多くありません。）

何が刺激的で十分に良いかについては...私はまだそれを見ていません、そして私は正確にどこを見るべきかを知るために空間全体に十分に精通していません。 もちろん、上記のとおり、多くの点でRustとはまったく異なる言語のように見えても、少なくともJuliaとTerraを一瞥したいと思うかもしれません。 オレグ・キセリョフがこの分野で多くの興味深い仕事をしてきたことを私は知っています。 TiarkRompfのScala用のLancetおよびLightweightModularStagingに関する作業は間違いなく一見の価値があるようです。 依存型のRustがどのように見えるかについての@kmcallisterによるプレゼンテーションを見たことを思い出します（少なくともどこにでもconstを貼り付けるよりも一般的かもしれません）。また、Olegから効果まで何かを見たことを思い出します。その型自体はステージングの形式です（コンパイルとランタイムの間の相分離がステージに非常に似ていることを考えると自然に感じます）...多くの異なる方向での多くのエキサイティングな潜在的な接続、それが見逃されたように感じる理由です私たちが思いついた最初の解決策にただコミットするなら、チャンスです。 :)

（これは単なるブレインダンプであり、私はほぼ確実に多くのことを不完全に特徴付けています。）

ただし、「組み込み言語」の大部分をサポートするのはかなり簡単なように思えますが、実際のコードは、メモリ割り当てを非常に迅速に行う必要性にぶつかります。 つまり、Vecまたはその他のコンテナを使用する必要があります。 そして、それはこの通訳スキーム全体が私の心にもっと複雑になり始めるところです。

私は、「実際の実際のコード」の特徴づけに同意しません。 Rustは、ヒープメモリの割り当ての必要性を減らすのに役立つため、大きな関心があると思います。 特に私のコードは、可能な限りヒープの割り当てを回避するために具体的な努力をしています。

それ以上のことができるのは_素晴らしい_ですが、コンパイラーによって強制された不変条件を使用して、自明でない型の静的インスタンスを構築できることが不可欠です。 C ++ constexprのアプローチは非常に制限されていますが、ユースケースに必要なものを超えています。パラメーターxを使用してタイプTのインスタンスを構築できる関数を提供する必要があります。 x 、 y 、およびzで、関数はx 、 y 、および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/もあります。
さびのような構文;）基本的に段階的な計算を対象としています
特定の部分評価。

2016年1月16日土曜日午後6時29分、Eduard-Mihai Burtescu <
[email protected]>は次のように書いています：

@glaebhoerlhttps ://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とは異なり）は_実際に_解除するのは現実的ではないようです。 そして、このシナリオでは、おそらく、そうでないものよりもはるかに多くのfnがconstの対象になります。

したがって、 constは、実装を公開する任意の制限を中心に展開することになり、ほとんどすべての場所にconstを書き込む必要があります。 それも魅力的に聞こえません...

つまり、生のポインタを使用すると、実行時のように直接メモリアクセスに変わるのではなく、割り当てられたアドレスのハッシュマップを検索するようなものになります。

@glaebhoerlええと、それは私が説明したモデルであり、 @tsionのmiriが実装しているモデルです。

FFIの区別は、一貫性のために_必須_である純度のために非常に重要だと思います。
unsafePerformIOがあるため、Rust const fnに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（11ではなくコメント31）にリンクするつもりだったと思います。

@tsion修正済み、ありがとう！

私が完全にポイントから外れている場合は、これを無視してください。

このRFCで私が目にする問題は、ユーザーとして、おそらくベストプラクティスになるため、できるだけ多くの関数const fnをマークする必要があるということです。 同じことが現在、contexprを使用するC++でも発生しています。 これは不必要な冗長性だと思います。

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について多くの議論がありました

ここでブロッカーを説明する最近のコメントは見当たりませんし、操作はあまり明るくありません。 ステータスはどうですか。 これをフィニッシュラインを越えて移動するにはどうすればよいですか？

これはRocketによって使用されます： https ：//github.com/SergioBenitez/Rocket/issues/19#issuecomment -269052006

https://github.com/rust-lang/rust/issues/29646#issuecomment-271759986を参照してください。 また、miriは「グローバルな副作用」に限界を押し広げているため、明示性に関する立場を再考する必要があります（ @solsonと@nikomatsakisはIRCでこれについて話していました）。

このRFCで私が目にする問題は、ユーザーとして、おそらくベストプラクティスになるため、できるだけ多くの関数constfnをマークする必要があるということです。

任意の関数を呼び出し可能にすることはできますが、それらの関数がCコードまたは静的関数にアクセスする場合、それらを計算することはできません。 解決策として、constfnである可能性のあるパブリック関数について警告するlintを提案します。

私はリントについて同意します。 これは、既存の組み込みのlint missing_docs 、 missing_debug_implementations 、およびmissing_copy_implementationsに似ています。

ただし、デフォルトでlintをオンにすると、ある種の問題が発生します。たとえば、後で関数を次のように変更する予定があるため、明示的にconstにしたくない関数について警告します。 constにすることはできず、インターフェイスをconstにコミットしたくありません（ constを削除することは重大な変更です）。

#[allow(missing_const)] fn foo() {}はそのような場合に機能すると思いますか？

@eddyb @nikomatsakis私の「 constの削除は重大な変更です」という点は、 fnがconstのままになることが下流への約束であるため、結局のところキーワードが必要であることを示唆しています。次のメジャーバージョンまで

constをstdや他のライブラリに振りかける必要があるのは残念ですが、公共の場でのみ必要とされない限り、どうすればそれを回避できるかわかりません-直面しているアイテム、そしてそれは紛らわしいルールのようです。

公開されているアイテムにのみ必要であり、それが紛らわしいルールのように思われる場合を除きます。

私はこれが好きです...私はそれが混乱することはないと思います。 const fnによって呼び出される関数を非定数にすることはできないため、パブリックインターフェイスは保護されています。

技術的には、関数にnotconstとして注釈を付ける方がよいでしょう。これは、他の方法よりもはるかに多くのconst fnがあると予想されるためです。

notconstは、Rustの設計哲学ともより一貫性があります。 （つまり、「 mut const 」）

公開されているアイテムにのみ必要であり、それが紛らわしいルールのように思われる場合を除きます。

私はこれが好きです...私はそれが混乱することはないと思います。

私はこのアイデアをフリップフロップしています。 これには利点があります（パブリックインターフェイスの決定を行うときconst fnについてのみ考えてください）が、混乱を招く可能性のある別の方法を考えました。

const fnによって呼び出される関数not-constを作成できないため、パブリックインターフェイスは保護されます。

これは真実であり、残念ながら、ライブラリの作成者がパブリック関数const constマークすると、その関数によって推移的に呼び出されるすべての関数も暗黙的にマークされることを意味します。意図せずに不要な関数にマークを付けているため、将来、非定数機能を使用してこれらの内部関数を書き直すことはできません。

他の方法よりもはるかに多くのconst fnがあると思います。

私はしばらくの間このように考えましたが、それは純粋なRustライブラリの木枠にのみ当てはまります。 FFIベースのfnsをconstにすることはできません（推移的にFFIベースである場合でも、多くのものがあります）。したがって、 const fnの金額はそれほど悪くない可能性があります。あなたと私が思ったように。

私の現在の結論：明示的でないconst fnは問題があるようです。 キーワードをたくさん書くのを避ける良い方法はないかもしれません。

また、記録として、 notconstは重大な変更になります。

@solson非常に良い点です。

特性メソッドで使用しようとすると、キーワードがさらに毛むくじゃらになることに注意してください。 トレイト定義に制限することは十分に有用ではなく、implsに注釈を付けると、不完全な「constfnparametrim」ルールになります。

そもそもconst fnを採用したとき、このトレードオフはかなり徹底的に議論されたように感じます。 @solsonの分析も正しいと思います。 変更されたのは、おそらく巡査fnsの割合が大きくなったということだけだと思いますが、ここでの基本的なトレードオフを変更するのに十分ではないと思います。 パブリックインターフェイスなどにconst fnを徐々に追加しなければならないのは面倒ですが、それは人生です。

@nikomatsakis私を悩ませているのは、これら2つの事実の組み合わせです。

• 事前にすべてをチェックすることはできませんunsafeコードは「動的に非定数」である可能性があります
• ジェネリックスとトレイトの実装に対して何をするにしても、それは「正しい」と柔軟なものの間のトレードオフになるでしょう。

「グローバルな副作用」がコードがconst fnになるのを妨げる主なものであることを考えると、これはRustが持っていて削除された「エフェクトシステム」ではないでしょうか。
「効果の安定性」について話すべきではありませんか？ 一部のライブラリがIMOをパニックに陥らないことを前提としたコードに似ているようです。

@eddybは絶対constはエフェクトシステムであり、そうです、それは私たちがそれらをできるだけ避けたいと思ったすべての欠点を伴います...私たちが追加の苦痛に耐えるつもりならそれはもっともらしいですエフェクトシステムでは、他の種類のエフェクトにスケーリングできる構文を検討することをお勧めします。 例として、 unsafe （これも効果）で同様の価格を支払っていますが、それらを統合することを考えるのが理にかなっているとは思えません。

違反が動的に発生する可能性があるという事実は、このオプトインを行うさらに多くの理由のように思えますが、そうではありませんか？

これはどう：

一般に、 const fnは、コンストラクター（ new ）または絶対に必要な場合にのみ使用する必要があると思います。

ただし、定数を簡単に作成するために、他の方法を使用したい場合があります。 constnessをデフォルトにすることで、多くの場合、この問題を解決できると思いますが、定義モジュールに対してのみです。 このように、すべてをconstにすることなく関数で定数を作成する便利さを持ちながら、 constで明示的に保証されない限り、扶養家族はconstnessを想定できません。

@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を宣言するための設計が明確ではなく、それらと特性の間の相互作用、およびどの程度の柔軟性が必要かについても確信がありません。

constfnの使用を安定させたいと思います。 これは人間工学的で表現力豊かな勝利のように思えますが、「通常のコードを書く」ことができるよりも、コンパイル時定数の評価を処理するためのより良い方法を想像することはできません。

constfnの使用を安定させます。

これにより、標準ライブラリの一部の関数がconstとして安定します。ライブラリチームは、少なくともいくつかの監査を行う必要があります。

@petrochenkovごとに監査される関数のリストとともに、呼び出しを安定させるためにPRhttps: //github.com/rust-lang/rust/issues/43017を提出しました。

特定の特性/implの状況でこれをどのように使用できるかについて質問/コメントがあります。 仮に、 Zeroの特性を持つ数学ライブラリがあるとしましょう。

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

この特性では、 zeroメソッドがconstである必要はありません。これにより、 Vec BigIntタイプによって暗示されるのを防ぐことができます。 ただし、マシンスカラーやその他の単純な型の場合、メソッドが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を予測する唯一の方法です。トレイトで、すべてのimplがconst fnである必要がある場合は、効果的に「 const impl s」を使用するよりもはるかに一般的ではありません。 。

@jethrogb可能ですが、constnessがimplのプロパティである必要があります。
私が念頭に置いているのは、たとえばT: Zeroがバインドされた一般的なconst fnには、 Tに対してZeroのimplが必要になるということです。 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()
    }
}

ボイラープレートはマクロで減らすことができます。

ほぼ同じことを行う2つの別個の特性（ ZeroとConstZero ）を持つという小さな不便さは別として、包括的実装を使用する場合に1つの潜在的な問題があります。

// 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（特殊化）の終わり近くに提案された「lattice」ルールのユースケースのように聞こえます。 あなたが書くなら

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バウンド）をチェックします。

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トレイトを使用せずに、関数が複数回呼び出されたときに常に同じものを返すことをどうにかして保証できれば幸いです。

必要な@Kixunilhttps ://github.com/rust-lang/rfcs/issues/1631

@jethrogbリンクをありがとう！

mem::size_ofが毎晩const fnとして実装されていることに気づきました。 これはmem::transmuteなどで可能でしょうか？ Rust組み込み関数はコンパイラーの内部で動作しますが、これを可能にするための適切な変更を行うのに十分な知識がありません。 それ以外の場合は、実装させていただきます。

残念ながら、値を操作することは、魔法のように値を作成するよりも少し難しいです。 transmuteにはmiriが必要です。 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を使用したいのですが、 @ nikomatsakisが、 const fnにされたときにそれらが不安定であることに懸念を表明していることを読みました。 。 特定の懸念があるのか​​、それとも一般的な注意があるのか​​はわかりませんが、IIRCが、機能ごとの機能ゲートが追加された理由です。 これら2つの懸念は、FCPを共有できるほど類似していると思います。 @rustbotが同じGitHubスレッドで別々のFCPを処理できるかどうかはわかりません。そのため、別々の問題を開く方がおそらく良いでしょう。

@durkaこれらすべての機能の安定性を安定させるために、単一の追跡問題を開くことができますか？ 立ち上がったらFCPを提案します。

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

alloc ::Layoutのconstfnsに関するディスカッションの先頭に立つには：
const fnでパニックを許容し、コンパイルエラーとして扱うことはできますか？ これは、定数の算術式で現在行われていることと似ていますね。

はい、ミリがマージされると、それは非常に些細な機能です

これは、追加のstd関数がconstになるように要求するのに適切な場所ですか？ もしそうなら、 Duration:: { new 、 from_secs 、 from_millis }はすべて安全にconstを作ることができます。

@remexreそれを実現する最も簡単な方法は、おそらくPRを作成し、そこでlibsチームのレビューを依頼することです。

https://github.com/rust-lang/rust/pull/47300としてPRします。 また、不安定なコンストラクターにconstを追加しました。

さらにstd関数をconstとして宣言できるようにすることについて何か考えはありますか？ 具体的には、 mem::uninitializedとmem::zeroed ？ これらは両方とも、追加のconst関数の適切な候補であると思います。 私が考えることができる唯一の欠点は、 mem::uninitializedの同じ欠点です。ここでは、 Dropを実装する構造体の作成が作成され、 ptr::writeなしで上書きされます。

よろしければ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関数ではないため、このコードはコンパイルされません。 Instant::now()をmem::uninitialized::<Instant>())に置き換えると、 mem::uninitializedがconst fnの場合、この問題が修正されます。 理想的には、プログラムが実行を開始すると、開発者はこの構造を初期化します。 このコードは非慣用的な錆と見なされますが（グローバルな状態は一般的に非常に悪いです）、これはグローバルな静的構造が役立つ多くのケースの1つにすぎません。

この投稿は、コンパイル時に実行される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と同じではなく、説得力のあるユースケースで必要ない場合は、これらの関数の使用を奨励するために何もする必要はないと思います。 。

最初に安定させることができるはるかに低いぶら下がっている果物があると思います。 miriがなければ、初期化されておらずゼロ化された組み込み関数はとにかくほとんど意味がありません。 でもいつか会いたいです。 最初にそれらを安定させ、中間の計算を初期化できない場合でも、すべての定数が初期化された結果を生成する必要があることを要求することもできます。

とは言うものの、ユニオンと安全でないコードを使用すると、とにかく初期化されていない、またはゼロにされたものをエミュレートできるため、それらを非定数に保つことにはあまり意味がありません

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チェックが、constfn内で不要なものを誤って許可/安定化しないように十分に厳密であるかどうかです。

rust-lang / rfcs＃2272を介してパターンとの統合を行うことはできますか？ パターンは現在のようにすでに痛いので、もっと痛くしないようにしましょう。

唯一の未解決の質問は、const fnチェックが、constfn内で不要なものを誤って許可/安定化しないように十分に厳密であるかどうかです。

私が間違っている場合は訂正してください。ただし、これらのチェックは、 const右辺値の本体で現在許可されているチェックと同じではありませんか？ 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!マクロが本当に欲しいのですが、不可能な場合はパニックになります。 このマクロは（miriを使用して）非const fnsを呼び出すことができるため、std内のすべての関数がconstfnとマークされるまで待つ必要はありません。 ただし、名前が示すように、いつでも失敗する可能性があるため、関数が更新されて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で絶対パスを禁止するための議論のように聞こえます😃

SystemTime ::nowをconstfnで許可すると、 const FOO: [u8; SystemTime::now()] = [42; SystemTime::now()];は、システムパフォーマンス、スケジューラ、およびJupiterの位置に応じてランダムにエラーになります。

さらに悪いことに：

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

TIMEの値がすべての使用サイトで同じであることを意味するわけではありません。特に、インクリメンタルを使用したコンパイル間およびクレート間で同じです。

さらにクレイジーなのは、 foo.clone()を非常に不健全な方法で台無しにする可能性があることです。これは、長さ3の配列からクローンimplを選択することになるかもしれませんが、戻り値の型は長さ4の配列である可能性があるためです。

したがって、任意の関数の呼び出しを許可したとしても、真の乱数ジェネレーターを許可しないのと同じように、SystemTime :: new（）が正常に戻ることを許可することはありません。

@ SoniEx2これはここでは少しオフトピックだと思いますが、カーゴbuild.rsファイルを使用して、今日すでにそのようなものを実装できます。 Cargo Bookのビルドスクリプト、特にコード生成のケーススタディのセクションを参照してください。

@ oli-obk 1つはAPIの安全性のバージョン管理に関するもので、もう1つはビルド環境に関するものであるため、完全に同じ問題ではないと思いますが、注意して適用しないと、どちらもエコシステムの破損につながる可能性があることに同意します。

const fnで現在の時刻を取得することを許可しないでください; ビルドを再現不可能にするために、より多くの/より簡単な方法を追加する必要はありません。

const fnにあらゆる種類の非決定論（乱数、現在の時刻など）を許可することはできません-rustcは定数式が常に与えられた同じ結果に評価されると想定しているため、型システムの不健全性につながる可能性があります同じ入力。 もう少し説明が必要な場合は、ここを参照してください。

https://github.com/rust-lang/rust/issues/24111#issuecomment -376352844のようなケースを処理するための将来の方法は、現在の時刻を取得してプレーンな数値として出力する単純な手続き型マクロを使用することです。文字列トークン。 手続き型マクロは、多かれ少なかれ完全に制限のないコードであり、非constRustコードが使用する通常の移植可能な方法のいずれかで時間を取得できます。

@rfcbotfcpマージ

これをマージすることを提案します。これは、やや健全なオプションであり、重大な変更ではなく、偶発的な重大な変更（他のクレートがconstコンテキストで関数を使用しているときに、constを評価できないように関数を変更する）を防止するためです。それについて本当に悪いことは、関数宣言の束の前にconstをスローしなければならないことです。

@ oli -obkに代わって@rfcbotfcpマージ-安定化について考え、問題を議論する価値があるようです

チームメンバー@nrcは、これをマージすることを提案しました。 次のステップは、タグ付けされた残りのチームによるレビューです。

• [x] @aturon
• [x] @cramertj
• [] @eddyb
• [x] @joshtriplett
• [] @nikomatsakis
• [x] @nrc
• [] @pnkfelix
• [x] @scottmcm
• [x] @withoutboats

懸念：

• デザイン（https://github.com/rust-lang/rust/issues/24111#issuecomment-376829588）
• parallel-const-traitsはhttps://github.com/rust-lang/rust/issues/24111#issuecomment-377133537によって解決されました
• 優先度（https://github.com/rust-lang/rust/issues/24111#issuecomment-376652507）
• runtime-pointer-addresses（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を要求し、このキーワードとswtichを非推奨にして、将来的に推定される恒常性を確保するための下位互換性があります。

1、2、および3を組み合わせると、将来のリリースで定数評価可能な関数のセットを拡張するよりも、今日constキーワードを安定させるための優れたオプションのようです。 しばらくすると、すべてを評価できる、徹底的に戦闘テストされたホニーアナグマの定数評価者が登場します。 その時点で、推定定数に切り替えることができます。

フォールアウトの危険性について：const fnは、特に埋め込みで、夜間に頻繁に使用されています。 また、const fnチェッカーは、静的初期化子および定数に使用されるチェッカーと同じチェッカーです（一部の静的固有のチェックと関数の引数を除く）。

私が見る主な欠点は、基本的に木枠全体にconstを自由にスプレーすることを提唱していることです（今のところ、将来のアイデアについては@matkladの投稿を参照してください）

@rfcbotはparallel-const-traitsに関係します

これを安定させると、すぐにたくさんのクレートが並列特性階層を作成し、先頭にConstが表示されます： ConstDefault 、 ConstFrom 、 ConstInto 、 ConstClone 、 ConstTryFrom 、 ConstTryIntoなど、 ConstIndexなどを要求します。 それはひどいことではありません-TryFromを安定させることは助けになりますが、今日は確かにTryで少しあります-しかし、少なくともそれをより良く解決するための計画のスケッチがあればいいと思います。 （それはhttps://github.com/rust-lang/rfcs/pull/2237ですか？わかりません）。

（ @nrc ：ボットはあなたの懸念事項の1つだけを登録したようです）

Parallel-const-traitsは、仮想の将来のconst-all-the-thingsバージョンで簡単な解決策を持っています。 彼らはただ働くだろう。

const fnの世界では、const fnトレイトメソッド（atmでは許可されていません）を許可しない限り、トレイトの重複が発生することはありません。 もちろん、関連する定数を（夜間に）作成することもできます。これは、libstdが1年前にあったような状況で、プライベートフィールドを公開せずに、静的/定数内のさまざまな型を初期化するための定数がたくさんありました。 しかし、それはすでにしばらくの間起こっていた可能性があり、そうではなかったものです。

明確にするために、 ConstDefaultは、 const fnなしで今日すでに可能であり、残りの例（ ConstFrom 、 ConstInto 、 ConstClone 、 ConstTryFrom 、 ConstTryInto ）は、@ oli-obkが述べたように、const traitメソッドを追加しないため、この機能が安定していても不可能です。

（ ConstDefaultは、関連付けられたconst fnではなく関連付けられたconstを使用することで可能ですが、私が知る限り、電力は同等です。）

特性定義の@scottmcm const fnは、今日は不可能です（ああ、 @ solsonはすでにそれについて言及しています）。

@eddybランダムなアイデア：トレイト定義にconst fnを追加する代わりに、トレイトをconst implできるようにした場合はどうなりますか？ （これら2つも相互に排他的ではありません。）

@whitequark https://github.com/rust-lang/rfcs/pull/2237は、 const implを組み合わせてfnごとにconst fnに拡張することで、そのアイデアをカバーしています。 implであり、すべてのconstメソッドでimplが、 constのメソッドをマークせずに、 T: const Traitの境界を満たすことを許可します。特性の定義自体。

@rfcbot懸念デザイン

私たちは歴史的に、いくつかの理由から、特定のconst fnシステムを安定させることに力を注いできました。

• 現在のものは、 const fnメソッドを必要とする$＃$ trait $＃$、またはconst fnメソッドを提供するトレイトimplをサポートしていません（https：//githubを参照）。これを行ういくつかの方法については、com / rust-lang / rfcs / pull / 2237）
• これに関連して、 T: Traitを介して使用されるメソッドを、個別の特性を持たずにconst fnにバインドして、できればコンパイル時に使用する場合にのみ要求するという問題があります（例： Option::mapは実行時に同じように機能しますが、CTFEでconst-callableクロージャが必要です）
• 多くのアルゴリズム、コレクション、および抽象化が潜在的に定数評価可能であるため、どこでもconst fnを使用するクレート全体が存在する可能性があります（ libcoreが思い浮かびます）

これらの問題のほとんどまたはすべてを（他の人を紹介することを犠牲にして）軽減するさまざまな設計上の選択があります。たとえば、これらは次のようなものです。

• アノテーションを必要とせず、コンパイラエラーを発行するだけで、miriは評価に失敗します
  
  
  
  • 長所：よりクリーンなコードベース、関連する値によっては、一定の評価がすでに失敗する可能性があります
  
  
  • 短所：言語レベルの動作ドキュメントとsemver境界がないため、他の人のコードをmiriにスローして、それらが行った小さな変更を観察できます。たとえば、依存関係の1つのパッチバージョンにランタイムデバッグログが追加されます。 また、価値の促進は行うのが難しい
  
  
• function / impl / module/etcごとに上記の動作をオプトインする方法。
  
  
  
  • これらの関数の本体は（少なくともconst fnに関しては）マクロのように動作します
  
  
  • 長所：semverの影響がなく、一部の分析の範囲が制限されている
  
  
  • 短所：まだ優れたドキュメントではなく、影響を受ける動作が明確ではありません（const-evaluatabilityだけですか？）、体の変化は、semver-breakingとしてカウントされる可能性があります
  
  

このようにすると、別のクレートの関数がコンパイル時に評価可能になるかどうかに応じてクレートが作成され、クレートの作成者が関数のシグネチャに影響を与えずに関数をコンパイル時に評価できないように変更する可能性があるためです。

@leoschwarzこれはすでに自動特性の問題ではありませんか？ おそらくこれに対する解決策は、錆びたセンバーと貨物を統合して、この種の意図しない破損を検出することです。

とは言うものの、miriに（ライブラリの作成者としての）あなたが誤って超過した評価時間制限があり、ダウンストリームでコンパイルが失敗した場合にどうなるかは私にはわかりません。

@nrc 「everything-const」は正しいと思いますが、問題ではありません。 はい、最終的には膨大な量のconstをマークすることになります。

推測されたすべてのものが欲しいかどうかわからないことを指摘したいだけです
const。 実行時間とコンパイル時間のどちらが長いかについての決定です
重要。 時々私はコンパイラがでかなり十分な計算をしていると思います
コンパイル時！

2018年3月28日水曜日午後2時49分、Josh [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はparallel-const-traitsを解決しました

訂正してくれてありがとう、皆さん！

その制限はすぐになくなります。

素晴らしい。 その場合、auto-const-fn（rust-semververの統合などと組み合わせて、破損に関する情報を提供する）は素晴らしいように聞こえますが、「ロギングを追加して破損を引き起こす」ことは問題になる可能性があります。 私が推測するバージョン番号を上げることはできますが、それは有限ではありません。

ロギングと印刷は、私の定数モデルでは「細かい」副作用です。 全員が同意すれば、その解決策を見つけることができるでしょう。 ファイルに書き込むこともできます（実際にはそうではありませんが、行ったように動作してすべてを破棄します）。

私は副作用を黙って捨てることを本当に心配しています。

それらの周りにRFCを作成したら、それについて話し合うことができます。 今のところ、定数に「副作用」を持たせることはできません。 トピックは、constfnの安定化と直交しています。

推測される「semverwarningを実行する」アプローチについて少し心配しています
恒常性。 恒常性について考えたことのない木枠の作者が見た場合
「警告：先ほど行った変更により、でfoo（）を呼び出すことができなくなります
以前は可能だったconstコンテキスト」、彼らはそれを
非sequiturとそれを沈黙させますか？ 明らかに、この問題の人々は頻繁に考えます
どの関数がconstになり得るかについて。 そしてもっと多くの人がやればいいのに
それ（const_fnが安定したら）。 しかし、すぐに使える警告は正しいですか
それを奨励する方法は？

2018年3月29日木曜日午前4時36分、Oliver [email protected]
書きました：

それらの周りにRFCを作成したら、それについて話し合うことができます。 今のところあなたはただ
定数に「副作用」を持たせることはできません。 トピックはに直交しています
constfnの安定化

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/24111#issuecomment-377164275 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAC3n3MtmvrDF42Iy0nhZ2q8xC-QGcvXks5tjJ0ggaJpZM4D66IA
。

明示的なconstfnは、多くのAPIを煩わしく混乱させる可能性があると思いますが、暗黙的に想定する代わりに、実行するには問題が多すぎると思います。

• constまたはnonconstと呼ばれる場合、副作用を破棄すると、コードの動作が異なる可能性があります（たとえば、ファイルの書き込みと読み取り）。
• extern関数を呼び出すと、常に副作用が発生する可能性があるため、安全でないコードをconstfnと推測することはできません。
• ジェネリックコードのconstfnはいつ推測できますか？ これは単形化時に行われますか？

しかし、明示しないことの最大の問題は、誰かが気付かないうちに1回の変更で誤って多くのコードを壊してしまう可能性があることです。 これは、Rustエコシステムで一般的な長い依存関係グラフで特に懸念されます。 関数シグネチャに明示的な変更が必要な場合は、これが重大な変更であることに気付くでしょう。

たぶん、そのような機能は、クレートのルート、 #![infer_const_fn]などに追加できるクレートレベルの構成フラグとして実装でき、永久にオプトインしたままになります。 フラグが追加された場合、const fnは可能な場合はクレートで推測され、ドキュメントにも反映されます（また、呼び出された関数もconst fnである必要があります）。クレートの作成者がこのフラグを追加した場合、注意が必要です。バージョン管理について、そして多分さびたsemververは強制されるかもしれません。

逆にそれをするのはどうですか？

const fnを使用するのではなく、sidefnを使用します。

それはまだ明示的であり（サイドfnを呼び出すにはサイドfnを配置する必要があり、明示的に互換性を壊します）、混乱を取り除きます。 （いくつかの）組み込み関数とasmを持つものはすべてサイドfnになります。

エディションに追加できると思いますが、下位互換性はありません。

2018年3月30日2:43:06AMGMT + 08：00、「SoniL。」 [email protected]は次のように書いています：

逆にそれをするのはどうですか？

const fnを使用するのではなく、sidefnを使用します。

それはまだ明示的です（サイドfnを呼び出すにはサイドfnを配置する必要があります。
明示的に互換性を壊します）、そして混乱を取り除きます。 （いくつか）
組み込み関数とasmを含むものはすべてサイドfnになります。

-
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/rust-lang/rust/issues/24111#issuecomment -377333542

-
K-9メールでAndroidデバイスから送信されました。 簡潔に申し訳ありません。

より大きな問題は、ほとんどのプログラミング言語が行うことではないので、初心者にとっては本当にショックになるということだと思います。

@whitequarkそれを行うだけのこと（「副作用を捨てる」）には同意しません。@ oli-obkは将来の拡張について話していたと思いますが、私が行った議論から、次のことがわかります。

• 「決定論的副作用」（不純なデータを返さない）を区別できます
• たとえば「コンパイル時にデータをログに記録する」場合は、特別なAPIを使用できます。
  
  
  
  • 増分オンデマンドコンパイルが必ずしも一貫した出力をもたらすとは限らないため、これは、必要な外部決定論のレベルによってはかなり困難です。
  
  
• 具体的には、現在存在し、グローバル/CFFIを使用しているものには触れません。

編集：議論が狂わないように、例えば：

constまたはnonconstと呼ばれる場合、副作用を破棄すると、コードの動作が異なる可能性があります（たとえば、ファイルの書き込みと読み取り）。

私たちは（おそらく？）そのような副作用を捨てることに関して@oli-obkのミスポークを想定することができます。

たぶん、そのような機能は、クレートのルートに追加できるクレートレベルの構成フラグとして実装できます。

これは、 https： //github.com/rust-lang/rust/issues/24111#issuecomment-376829588からの過去の提案の2番目の例のサブセットです。
スコープが「構成フラグ」である場合、ユーザーはよりきめ細かいスコープIMOを選択できるはずです。

逆にそれをするのはどうですか？
const fnを使用するのではなく、sidefnを使用します。
それはまだ明示的であり（サイドfnを呼び出すにはサイドfnを配置する必要があり、明示的に互換性を壊します）、混乱を取り除きます。 （いくつかの）組み込み関数とasmを持つものはすべてサイドfnになります。

https://github.com/rust-lang/rust/issues/24111#issuecomment -376829588で、ライブラリ全体が「すべてconst fn 」または「すべてside fn 」になる可能性があることを指摘しようとしました"。
関数宣言ではなくスコープが設定されていれば、将来のエディションで機能する可能性があります。
ただし、「身体から推測する」セマンティクスがないと、オプトインside fnの場合でも特性の相互作用を設計する必要があるため、何も得られず、潜在的に大きな摩擦が発生します。

Kenton Vardaの「有害と考えられるシングルトン」の記事のセクション3.3は、ここに関連しているようです（正直なところ、すべてを読む価値があります）。

デバッグログはどうですか？

実際には、すべてのコードでデバッグログを利用できるようにする必要があることを誰もが認めています。 例外とします。 この例外の正確な理論的根拠は、気になる人のために、いくつかの方法で提供できます。

セキュリティの観点から、デバッグログは無害なシングルトンです。 書き込み専用のため、通信チャネルとして使用できません。 また、デバッグログはプログラムの正確さの要因ではないため、デバッグログに書き込むことによって何らかの損害を引き起こすことは明らかに不可能です。 悪意のあるモジュールがログを「スパム」した場合でも、デバッグログは通常、各メッセージを生成したモジュールを正確に識別するため、そのモジュールからのメッセージは簡単に除外できます（スタックトレースを提供する場合もあります）。 したがって、提供しても問題ありません。

デバッグログが読みやすさ、テスト容易性、または保守性に害を及ぼさないことを示すために、同様の議論を行うことができます。

デバッグログのもう1つの理論上の正当性は、デバッグログ関数は実際にはデバッガーによって観察される単なる操作なしであると述べています。 デバッガーが実行されていない場合、関数は何もしません。 一般に、デバッグは明らかにオブジェクト機能モデル全体を破壊しますが、明らかに特権操作でもあります。

「[デバッグ用の]解決策を見つけることができる」という私の発言は、実際には、constsから呼び出すことができるが、何らかの形で印刷される潜在的な将来のAPIに言及していました。 プラットフォーム固有の印刷操作をランダムに実装すること（print / debugステートメントを使用して既存のコードをconstにすることができるようにするため）は、constエバリュエーターが行うべきことではありません。 これは純粋にオプトインであり、観察可能な動作が明示的に異なることはありません（たとえば、実行時のconst evalおよびコマンドライン/ファイル出力での警告）。 正確なセマンティクスは将来のRFCに委ねられており、一般にconstfnに対して完全に直交していると見なす必要があります。

const impl TraitとT: const Traitに重大な欠点はありますか？

constの周りにさらに多くのスプレーをかける以外に、一部の特性メソッドのみがconstである可能性があり、よりきめ細かい制御が必要になります。 しかし、それを指定するためのきちんとした構文はわかりません。 たぶんwhere <T as Trait>::some_method is const （ isはコンテキストキーワードである可能性があります）。

繰り返しますが、これはconstfnに直交します。

[u8; SizeOf<T>::Output]

constとsidefnsが分離している場合は、実際の設計上の考慮事項を考慮する必要があります。 それらを分離する最も簡単な方法は、const fnsを、現在あるもの、つまりチューリング完全型システムの拡張にすることです。

または、const fnsを実際にconstにします。constfnはすべて、すべてのパラメーターがconstジェネリックであるかのように評価する必要があります。

これにより、現在のconst fnsについて個人的に推論することができないため、推論がはるかに簡単になります。 チューリング完全型、マクロ、通常のfnsなどについて推論することはできますが、細かい部分でも意味が完全に変わるため、constfnについて推論することは不可能です。

細かい部分でも意味が完全に変わるからです。

詳細を教えていただけますか？ const fnポインター、 constトレイト境界などの拡張機能を意味しますか？ むき出しのconst fnの提案には細かい詳細が見当たらないからです。

または、const fnsを実際にconstにします。constfnはすべて、すべてのパラメーターがconstジェネリックであるかのように評価する必要があります。

これがコンパイル時に行っていることです。 実行時に、この関数は他の関数と同じように使用されます。

問題は、細かい部分があれば、定数評価が実行時評価に変わる可能性があることです。 これは、最初は大したことではないように思われるかもしれませんが、そうなる可能性があります。

すべてconstfnsであるため、関数呼び出しが本当に長いとしましょう。 そして、それを複数の行に分割したいと思います。

したがって、いくつかのletを追加します。

これで、プログラムの実行に20倍の時間がかかります。

@ SoniEx2配列のサイズ（ $N [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.
}

ここで、引数を取るconstfnがあるとします。 これはコンパイル時に評価されます：

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 「最小constfn」が将来のすべての拡張機能と上位互換性があるという観察によって、設計上の懸念を解決できるかどうか疑問に思います。 つまり、私は安定したいということです

フリー関数と固有のメソッドをconstとしてマークし、定数引数を使用して定数コンテキストで呼び出すことができるようにします。

これは、「特性の定数効果」設計と簡単に完全に上位互換性があるようです。 後でconstオプションにすることができるため、「推定定数」設計とも互換性があります。

現在の「最小定数fn」提案と互換性のない代替の将来の設計はありますか？

@nrc

rfcbotはeverything-constの懸念事項を登録しなかったことに注意してください（コメントごとに1つの懸念事項！）ただし、これは設計上の懸念事項のサブセットのようです。これは、以前のコメント（TL; DR：現在の最小限の提案）で対処されています。すべてと完全に互換性があるため、将来的にconstキーワードをオプションにする可能性があります）。

優先順位/放射性降下物の懸念については、私たちがすべての手で議論したことと、まだ文書化していないことを文書化したいと思います。

• const fn foo(x: i32) -> i32 { body }は、 const FOO: i32 = body;を超える比較的マイナーな追加であるため、フォールアウトのリスクはわずかです。 つまり、実際にconst fnを実装するコードのほとんどは、安定したコンパイラですでに懸命に機能しています（免責事項：これは@ oli-obkから聞いたもので、間違って聞いた可能性があります）。

• 埋め込まれたワーキンググループはconstfnをひどく望んでいます:)

さらに、 const fnを安定させないと、ライブラリ内で最適ではないAPIが急増することに注意してください。これは、const fnsの不足を回避するために、 ATOMIC_USIZE_INITなどのトリックを使用する必要があるためです。

i = random（）;とします。 //このバインディングのRHSはコンパイル時に評価され、実行時にランダムへの呼び出しはありません。

いいえ、それはまったく起こっていません。 発生している可能性がありますが（おそらく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％を2回書き込む必要がありますか？1回はconst eval用、もう1回はruntime用ですか？ 同じことがおそらく他の多くの箱にも当てはまります。

私はAtomicUsize::Of<value>を考えていました。 そして、はい、私は未知の保証をするよりもむしろすべてを二度書く必要があります。 （さらに、これは、何かが検証されているかどうかに基づいて異なる動作をすることはありません。）

const評価を保証するためにconstfnでconstsを宣言できますか（再帰的な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評価を保証するためにconstfnでconstsを宣言できますか（再帰的なconst fnの場合）？ または、constジェネリックを通過する必要がありますか？ 等。

const fnのポイントは、コンパイル時に魔法のように物事を評価することではありません。 コンパイル時に物事を評価できるようにすることです。

rustcはllvmに基づいていたため、コンパイル時に魔法のように物事を評価することはすでに行われています。 だから...まさにそれがocamlで実装されなくなったとき。 rustcから定数伝播を削除したいと思う人はいないと思います。

const fnは、定数の伝播にはまったく影響しません。 誤ってconstが伝播される可能性のある関数があり、llvmがそれを行った場合、その関数をconstが伝播できないように変更すると、llvmはそれを停止します。 これは、 constを関数にアタッチすることとは完全に独立しています。 llvmにとって、 const fnとfnの間に違いはありません。

同時に、 constをfnにアタッチしても、rustcの動作はまったく変わりません（関数が有効な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が長い間毎晩焼かれていることを除いて、私は優先事項+放射性降下物の懸念について本当に話すことはできません

他の2つのポイントは密接に関連しています。 @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である必要がありますか？
  
  
  
  • 繰り返しますが、オプトアウトが必要になります
  
  

これらのことを考える必要があるので、consteval中に関数ポインターを介して関数を呼び出すことができるようにしたい将来のバージョンと互換性のないシステムを設計しません。

私は特定のデザインを提案したのではなく、いくつかの既知のもっともらしい方向性をリストしただけであることに注意してください。
元のアイデアは、 constに限定されない、一般化された「関数の本体を公開する」属性でしたが、多くの可能なバリエーションがあり、それらのいくつかは良いかもしれません。

編集:(これを忘れたくない） @solsonは、関数の本体からさまざまなものを自動的に導出する@patternのような属性がLeanにどのようにあるかを示していました。

@ oli-obk unsafeは属性を使用しないため、属性を使用するべきではないと思います。
また、 asyncも現在はそうではありません。 そして、 try { .. }ブロックを指定してtry fnを導入すると、属性ベースではない別のものがあります。 効果のようなものをできるだけ一貫性を保つように努めるべきだと思います。 属性を使用するかどうか。 #[target_feature(..)]は、全体的な一貫性にシワを付けます。

PS： 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 fnを呼び出すと、今日は問題なく機能します。

@ oli-obk特性はどうですか？ トレイトのimplの一部でのみconst fnであるトレイトメソッドに対して何をするのかを理解せずに、 const fnを安定させたくありません。

@eddybは、新しいconst境界とメソッドの記述を促進する必要があるようです。 :)

@Centril私のポイントは、属性の提案（キーワードを使用するかどうかに関係なく）は、特性メソッドを処理するためのはるかに異なるアプローチをもたらすということです。それを比較する必要があります。
現在のconst fnアプローチは単純で拡張可能に見えるかもしれませんが、実際に拡張された場合はそうではありません。

ジェネリックconsts+constジェネリック：

intrinsic const SizeOf<T>: usize;

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

@eddybconstfnデザインと完全に互換性のあるさまざまなソリューションを念頭に置いています。 書きます。

うわー、私はちょうどそれが始まったのは2年であるのを見ました。 安定化の予見日はありますか？ この拡張機能が安定するのを待つため、 stableでほぼ利用できるクレートがあります。 :)

@rfcbotはruntime-pointer-addressesに関係します

別の問題で、 const fnからの参照透過性が必要かどうかという質問が発生し、生のポインターのアドレスが非決定論のオラクルとして使用されるという問題が発生しました： https ://github.com/rust- する前に、いくつかの生のポインター操作を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になるものもありますが、それらは簡単に禁止されます（実行時/評価時に既にポインターを追跡しているため、ポインター変換への使用を禁止します）。

浮動小数点については、NaN正規化？

私はそれらの両方が全体を決定論的にするだろうと思います。

これはおそらく、たとえばNaNペイロードのために、floatのビットを取得することも問題であることを意味します。

完全な参照透過性を得るには、すべてのフロート操作を危険にさらす必要があると思います。

浮動小数点の決定論は難しい

ここで最も重要な点は、LLVMのオプティマイザーは、フロート操作の順序を変更できることと、オペコードを組み合わせた操作を〜実行〜することです。 これらの変更は、実際の違いがわずかであっても、操作の結果に影響を与えます。 miriはllvmに最適化されていないmirを実行し、ターゲットはllvmに最適化され、場合によっては並べ替えられ、したがってネイティブコードとは異なるセマンティクスを実行するため、これは参照透過性に影響します。

参照透過性がどれほど重要であるかが決定されるまで、フロートのない最初の安定したconst fn機能に同意しますが、その議論によってconstfnの速度が低下したりブロックされたりすることは望ましくありません。

ここで最も重要な点は、LLVMのオプティマイザーは、フロート操作の順序を変更できるほか、オペコードを組み合わせたヒューズ操作を実行できることです。 これらの変更は、実際の違いがわずかであっても、操作の結果に影響を与えます。

融合操作（mul-addを参照していると思います）は、結果の丸めを変更するため、高速演算フラグなしでは許可されません/実行されません。 LLVMは、IEEE準拠のハードウェアを対象とする場合、「デフォルトの浮動小数点環境」によって設定された制限内で、浮動小数点演算の正確なセマンティクスを維持するように細心の注意を払っています。

LLVMが保持しようとしない2つのことは、NaNペイロードとNaNのシグナリング性です。これらは両方とも、デフォルトのfp環境では観察できないため、フロートのビットを検査するだけで、禁止する必要があります。 （そして、LLVMがそれらにもっと注意を払っていたとしても、ハードウェアはNaNペイロードの処理も異なるため、これをLLVMに固定することはできません。）

コンパイラの決定が浮動小数点の結果に影響を与える可能性があることを私が知っている他の主要なケースは、 x87 （pre-SSE）コードでのスピルとリロードの場所です。 x87はデフォルトで中間結果の場合は80ビットに丸められ、ストアの場合は32ビットまたは64ビットに丸められるため、これは主に問題です。 正しく丸められた結果を達成するために、各FPU命令の前に丸めモードを適切に設定することは可能ですが、実際には実用的ではないため、LLVMはそれをサポートしていません。

完全な参照透過性について

私の見解では、完全な参照透過性を使用する必要があります。これは、安全性/利便性/完全性よりも正確性を選択するという全体的なRustメッセージと一致するためです。

参照透過性は、等式推論を可能にするなど、多くの推論の利点を追加します（ボトムまでですが、速くて緩い推論は道徳的に正しいです）。

ただし、もちろん欠点もあります。 完全性を失う。 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内の追跡されたポインターを返す必要があります。

変換の結果、コンパイル時（つまり、const評価）で0になります。 非定数評価では、何でも返されます。

追跡されたポインタは次のように機能します。

ポインタを割り当て、それを割り当てます。 割り当てると、VMはポインタ値を0に設定しますが、ポインタのメモリアドレスを取得し、ルックアップテーブルにアタッチします。 ポインタを使用するときは、ルックアップテーブルを調べます。 ポインタの値（つまり、それを構成するバイト）を取得すると、0が取得されます。これがオブジェクトのベースポインタであると想定します。

Box :: newは、VM内の追跡されたポインターを返す必要があります。

ここでは、実行時の動作について説明しています。 のように、これがバイナリで実行されるとどうなりますか。 VMはありません。

miriは、これらすべてをすでに問題なく、完全に決定論的に処理できます。

また、 const fnとランタイム決定についての懸念に戻ります：それが必要な場合（私たちがそうするかどうかはわかりませんが、なぜ私たちが気にするのか説明するのを待っています：D）、宣言することができますptr-to-intおよびfloat-to-bitsは、非定数演算になります。 何か問題はありますか？

@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から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です。

@ SoniEx2はfoo as *const _ as usize as *const _を壊しますが、これは今のところ完全にヌープです

Wrtの動機：
個人的には、実行時の動作がコンパイル時の動作と異なる問題や、constfnが実行時に非決定的であるという問題は見られません。 ここでは安全性は問題ではないので、安全でないというのは完全に間違ったキーワードimoです。 これは、コンパイル時の評価で完全にキャッチしている驚くべき動作です。 あなたはすでに通常の機能でこれを行うことができるので、そこに驚くことはありません。 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から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などを指定したものが必要だと思います（何かhttps：// github.com/rust-lang/rfcs/pull/2237ですが、いくつかの変更があります...）そしてパラメトリシティはそのための良いアイデアのようです。

PhilWadlerとConorMcBrideの不滅の言葉で：

私は純粋なのか、それとも不純なのか？
—フィリップ・ワドラー[60]

私たちは「はい」と言います：純度は地元で作る選択です

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

@ oli-obk

実行時またはコンパイル時に同じ引数を指定して実行すると、実行結果がconst fnで異なる可能性があるという、この驚くべき動作を文書化する必要がある人をうらやましく思いません。

保守的なオプションとして、 const fnを参照透過性として安定させ、 unsafe （または非const ）に違反させることにより、参照透過性/純度に関する決定を遅らせることを提案します。ただし、実際には参照透過性を保証するものではないため、人々もそれを想定することはできません。

後で経験を積んだら、決断を下すことができます。
経験を積むことには、非決定論を利用しようとして失敗した人々が含まれ、それを報告して、彼らのユースケースについて私たちに話します。

はい、しかしそれはconst評価ではありません。

constでintをptrに変換することは、大きな損失のようには見えません。 フィールドオフセットを取得することがより重要であるように思われ、それが私が維持しようとしていることです。

constを関数@ SoniEx2に追加するときの動作を黙って変更したくありません。これは、基本的にあなたの提案が行うことです。

@centril同意します、今は保守的なことをしましょう。 したがって、これらを危険にさらすことはありませんが、不安定にします。 このようにしてlibstdはそれを使用できますが、後で詳細を決定できます。

私たちが抱えている問題の1つは、ユーザーがユニオンを導入し、いくつかの凝った変換を行うことで、いつでも分析をブリックできることです。そのため、後で変更できるように、このような回避変換UBを作成する必要があります。

それは実行時にまだ同じであり、constはconst時にのみ変更を行いますが、これは...constなしでは実行できません。

const fnsが、異なるポインタエイリアシングルールを持つサブ言語であるのは問題ありません。

@Centril @ est31クロロトリフルオロエチレンが何かと何の関係があるのか​​わかりません（頭字語を定義せずにたくさんの頭字語を使用することを避けられますか？）

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

@sgrif CTFE（コンパイル時関数評価）は、Rustに長い間使用されてきました（このスレッドの何年も前の部分を含む）。 これは、すでに中心的な場所で定義されている必要がある用語の1つです。

@sgrif lol申し訳ありませんが、私は「彼らは今、どの奇妙な言葉を使っているのか」と疑問に思っている人です。 彼が「CTFE」と言ったとき、私はIRCの@eddybと話していたと思います。そして、それが何を意味するのかを彼に尋ねなければなりませんでした：p。

このページの@eddybctrl + f + CTFEは、それを定義するものにはなりません。 いずれにせよ、私はほとんどの場合、ここでの議論に参加するために人々に多くの掘り下げを強制したくないという仮定に基づいています。 「これが何を意味するのかをすでに知っているはずです」はかなり排他的なIMOです。

@Centril @ est31ありがとう：heart：

だから...についての考え

私たちが抱えている問題の1つは、ユーザーがユニオンを導入し、いくつかの凝った変換を行うことで、いつでも分析をブリックできることです。そのため、後で変更できるように、このような回避変換UBを作成する必要があります。

したがって、const fn内のユニオンフィールドアクセスも不安定である必要がありますか？

このページのctrl+f + CTFEは、それを定義するものにはなりません。

申し訳ありませんが、それが意味するのは、 Rustの設計と開発での使用は、この1.0より前の問題よりも前のことです。
そのような用語の中心的なドキュメントがあるはずですが、悲しいことに、リファレンスの用語集は本当に不足しています。
HRTBとNLLは、他の頭字語の2つの例であり、新しいものですが、インラインでは説明されていません。

議論を排他的にしたくはありませんが、@ Centrilまたは@est31のどちらにも頭字語を最初から導入していないため、CTFEの定義を依頼するのは公平ではないと思います。
悲しいことに、GitHubで必ずしも機能しないソリューションがあります。これは、ボットがトップレベルのコメントを作成して更新し続ける、一般的に使用されるすべての頭字語の拡張リストを含む、特定のサブレディットで見たものです。そのsubredditの議論に現れます。

また、CTFEに関する2つのウィキペディアの記事（「クロロトリフルオロエチレン」と「コンパイル時関数の実行」）が最初の2つの結果であるため、Googleのバブルにいるのかどうか知りたいです。 それでも、前者は「コンパイラ機能については、コンパイル時関数の実行を参照してください」で始まります。

（ CTFE wikiリンクを一番上に配置しました。では、 const fn sに戻ってください。：P）

誰かがRTFEをrustcガイド用語集に追加できますか（私はモバイルを使用しています）？

また、最低限を安定させて、実際に多くの人が遭遇するものを確認する必要があると思います。これは、constifおよびmatch式を使用した現在のアプローチになります。

@Centril

実行時またはコンパイル時に同じ引数を指定して実行すると、const fnの実行結果が異なる可能性があるという、この驚くべき動作を文書化する必要がある人をうらやましく思いません。

上で書いたevenは、ポインターのビットを検査するため、CTFE時に実行すると失敗します。 （実際には、これはアライメントのせいであると決定論的に言うことができます。均一性テストがビット演算で実行される場合、「フルミリ」はそれを適切に実行します。ただし、最下位バイト全体をテストしていると仮定します。最後のビット。）
ここで説明しているのは、コンパイル時にインタープリターエラーでエラーが発生するが、実行時には成功する関数です。 違いは、関数が実行を完了するかどうかです。 それを説明するのは難しいとは思いません。

CTFEが結果で成功した場合、関数の実行時バージョンも同じ結果で成功することが保証されるべきであることに同意します。 しかし、それは私たちがここで話していることよりもはるかに弱い保証ですよね？

@ oli-obk

同意します。今は保守的なことをしましょう。 したがって、これらを危険にさらすことはありませんが、不安定にします。 このようにしてlibstdはそれを使用できますが、後で詳細を決定できます。

私は文脈を失いました、ここで「これら」は何ですか？

現在、幸いなことに、CTFE miriは、ポインター値（算術、比較、すべてのエラー）を使用して何もすることを完全に拒否しています。 これは、計算で実際に使用される値に基づいてCTFE時に実行されるチェックであり、ユニオンによって回避することはできません。とにかく、算術/比較を実行するために必要なコードは存在しません。 したがって、私は上記の保証を満たしていると確信しています。

CTFEがポインター値を返すようにすると問題が発生する可能性がありますが、コンパイル時に計算されたポインター値はどこでも意味がありますか？ ポインタ値をビットに変換する必要があるため、miriが計算するポインタ値が含まれていないことをすでに確認していると思いますか？

CTFE miriに操作を注意深く追加することができます。実際、 @eddybのoffset_of[1]に必要なのは、ポインターの減算だけです。 そのコードは「fullmiri」に存在し、両方のポインターが同じ割り当て内にある場合にのみ成功します。これは、上記の保証を維持するのに十分です。 うまくいかないのは、 @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->ビット変換とポインタ->usize変換です

CTFEが結果で成功した場合、関数の実行時バージョンも同じ結果で成功することが保証されるべきであることに同意します。 しかし、それは私たちがここで話していることよりもはるかに弱い保証ですよね？

したがって、実行時に引数を使用して呼び出された関数は、コンパイル時に同じ引数を使用して評価された場合に実際に終了した場合にのみ、純度が保証されますか？

それは私たちの生活を何百万倍も楽にしてくれるでしょう。特に、抜け穴を残したり、const fnを壊滅的な方法で壊したりせずに、非決定性を防ぐ方法が見当たらないからです。

したがって、実行時に引数を使用して呼び出された関数は、コンパイル時に同じ引数を使用して評価された場合に実際に終了した場合にのみ、純度が保証されますか？

はい、それが私が提案していることです。

もう少し考えてみると（そして私がこれを書いている間に現れた@ oli-obkの返信を読んで）、あなたが望むのは「安全なconst fnはエラーにならない」という線に沿った追加の保証であると感じます有効な引数で呼び出された場合のCTFE時間（パニック以外）」。 ある種の「一定の安全性」の保証。 実行時の動作と一致するCTFEの成功について前述した保証とともに、安全なconst fnは、成功したCTFEの実行と一致するため、実行時に決定論的であるという保証を提供します。

私はそれが取得するのが難しい保証であることに同意します。 良くも悪くも、Rustには、決定論を維持しながらCTFE miriが常に正常に実行されることを保証できないさまざまな安全な操作があります。たとえば、最下位バイトが0であるかどうかをテストする@Centrilのoracleのバリアントなどです。この設定でのCTFEの場合、「タイプusizeの有効な値」は、 PrimVal::Bytesの値のみを構成しますが、 PrimVal::Ptrは許可されません[1]。 constコンテキストでは、型システムが少し異なるようです。miriの機能を変更することを提案しているのではなく、 const fnにアタッチされたときにさまざまなRust型が「意味する」ことを変更することを提案しています。 このような型システムは、CTFEですべての安全な算術演算とビット演算が失敗しないことを保証します。CTFEが有効な入力の場合、両側がPrimVal::Bytesであるため、CTFEで整数減算が失敗することはありません。 もちろん、ptr-to-intの戻り値の型usizeですが、CTFEで有効なusizeではないため、この設定ではptr-to-intは安全でない操作である必要があります。

これが私たちが気にかけている保証である場合、CTFE関数をチェックするときに型システムをより厳密にすることは私には不合理に思えません。 結局のところ、私たちはそれをもっと多くのことをするために使いたいのです（「一定の安全性」をチェックする）。 それなら、ptr-to-intキャストを$ constコンテキストでunsafeと宣言することは非常に理にかなっていると思います。これは、 constコンテキストが追加の保証。

私たちの通常の「実行時の安全性」が安全でないコードによって破壊される可能性があるのと同じように、「一定の安全性」も破壊される可能性があり、それは問題ありません。 安全でないコードがユニオンを介してptrからintへのキャストを実行できることに問題はありません。結局のところ、これは安全でないコードです。 この世界では、constコンテキストでの安全でないコードの証明義務は、非constコンテキストでの証明義務よりも強力です。 関数が整数を返す場合、これが常にPrimVal::Bytesであり、決してPrimVal::Ptrではないことを証明する必要があります。

@eddybのマクロには安全でないブロックが必要ですが、これらの「const unsafe features」（ptr-to-usizeしてから結果を減算するか、またはポインター減算組み込みを使用する）のみを使用するため、安全に使用できます。直接）CTFEエラーを発生させないことが保証されている方法で。

このようなシステムのコストは、安全な高次のconst fnがconst fnのクロージャーを取得して、クロージャーの実行自体が「定数の安全性」に違反しないことを保証できるようにする必要があることです。 これは、安全なconst fnについて実際に適切な保証を取得するための価格です。

[1]非決定論がどこで発生するかについてはよくわからないため、ここではフロートを完全に無視しています。 CTFE時と実行時で動作が異なる浮動小数点コードの例を誰かが提供できますか？ たとえば、浮動小数点演算を実行するときに、オペランドの1つがシグナリングNaN（最初の保証を取得するため、前の投稿からのもの）である場合は、miriエラーを作成し、CTFE型システムと言うだけで十分でしょうか。タイプf32 / f64でのNaNのシグナリングを許可しませんか（「一定の安全性」を取得するため）？

うまくいかないのは、 @eddybがセーフガードとして追加したという主張です。

もちろんですが、今のところassert!(condition);を[()][!condition as usize];に書き換えることができます。

もちろんですが、assert！（condition）;を書き換えることができます。 to [（）] [！condition as usize]; 今のところ。

それは私が考えていた主張ではなく、あなたの状態でのポインター同等性テストです。 ポインターの平等は悪であり、CTFEでそれを許可できなかった場合は私が望んでいます。

編集：気にしないでください、私はassertがオフセットをテストすることに気づきました。 したがって、実際には、CTFE時に失敗することはありません。これは、 wrapping_subを実行するときにポインターが同じブロックにない場合、miriがエラーになるためです。

// 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番目のビットの均一性を取得することは決定論的ではありません。 仮想ポインタを使用すると、決定論的になります。 実際のポインタでは、決定論的ではありません。 1つはコンパイル時に発生し（決定論的環境）、もう1つは実行時に発生する（非決定論的環境）ため、これは問題ありません。

const fnは、使用されている環境と同じくらい決定論的である必要があります。

@ SoniEx2

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

確かにできません。 割り当てられたオブジェクト内にあるという意味で、どちらかのポインターが現在参照解除できない場合にエラーが発生するバージョンのrawポインター比較を使用できると思います（ただし、これは「フルミリ」が現在実装しているものではありません）。 ただし、それでもis_eqは「constsafe」ではありません。 Tのサイズがゼロの場合、安全なコードのみを考慮しても、オブジェクトの終わりの1つ先を指す可能性があるためです。

C ++では、ポインターを最後から1つ比較して、不確定な（非確定的な）結果を生成できます。 CとC++はどちらも、ダングリングポインターを比較して、不確定な結果を生成することができます。 LLVMが何を保証するかは明確ではありませんが、C / C ++に対して保証する必要があるもの（異なる場合は2つのうち弱い方）を超える保証には賭けたくありません。 これは、CTFEで正常に実行されるすべての実行時の決定論を保証したい場合に問題になります。これは、私たちが行っていると思います。

@RalfJung

違いは、関数が実行を完了するかどうかです。

悪魔の主張：ある場合の「戻る⊥」は、結果が異なるのと同じです。

それを説明するのは難しいとは思いません。

個人的に私はそれを驚くべき行動だと考えています。 あなたはそれを説明することができます、そして私は理解するかもしれません（しかし私は代表ではありません...）、しかしそれは私の直感に合いません。

@ oli-obk

したがって、実行時に引数を使用して呼び出された関数は、コンパイル時に同じ引数を使用して評価された場合に実際に終了した場合にのみ、純度が保証されますか？

個人的には、この保証は十分ではないと思います。 最初に、純粋さでどこまで到達できるかを確認する必要があります。実際に問題が発生していることがわかった場合にのみ、より弱い保証に移行する必要があります。

@RalfJung

これにより、CTFEの実行の成功と一致するため、安全なconstfnが実行時に決定論的であることが保証されます。

わかった; あなたは私を失った。 2つの前提を考えると、この「安全な定数fnは決定論的」保証にどのように到達したのかわかりません。 理由を詳しく教えていただけますか？

これが私たちが気にかけている保証である場合、CTFE関数をチェックするときに型システムをより厳密にすることは私には不合理に思えません。 結局のところ、私たちはそれをもっと多くのことをするために使いたいのです（「一定の安全性」をチェックする）。 したがって、constコンテキストでは追加の保証が行われるため、これが必要であると主張して、ptr-to-intキャストをconstコンテキストで安全でないと宣言することは非常に理にかなっていると思います。

私たちの通常の「実行時の安全性」が安全でないコードによって破壊される可能性があるのと同じように、「一定の安全性」も破壊される可能性があり、それは問題ありません。 安全でないコードがユニオンを介してptrからintへのキャストを実行できることに問題はありません。結局のところ、これは安全でないコードです。 この世界では、constコンテキストでの安全でないコードの証明義務は、非constコンテキストでの証明義務よりも強力です。 関数が整数を返す場合、これが常にPrimVal::Bytesであり、決してPrimVal::Ptrではないことを証明する必要があります。

これらの段落は私の耳に聞こえる音楽です！ ❤️これは決定論（「純度」）を保証するように見えますか？ まさに私が以前に考えていたものです。 constの安全性も素晴らしい用語だと思います！

将来の参考のために、この保証を「CTFEの健全性」と呼びましょう。CTFEにエラーがない場合、その動作は実行時に一致します。両方が発散するか、両方が同じ値で終了します。 （ここでは、高次の戻り値を完全に無視しています。）

@Centril

悪魔の主張：ある場合の「戻る⊥」は、結果が異なるのと同じです。

まあ、それは明らかに定義の問題です。 あなたは私が説明したCTFE健全性保証を理解したと思います、そしてあなたはそれが私たちが望む保証であることに同意します。 それが私たちが望むすべてであるかどうかは議論の余地があります:)

わかった; あなたは私を失った。 2つの前提を考えると、この「安全な定数fnは決定論的」保証にどのように到達したのかわかりません。 理由を詳しく教えていただけますか？

foo(x)を呼び出したとします。ここで、 fooは安全なconst関数であり、 xはconst-valid値です（つまり、 &y as *const _ as usizeではありません）。 ）。 次に、constの安全性により、 foo(x)がエラーを発生させることなくCTFEで実行されることがわかります。 結果として、CTFEの健全性により、実行時にfoo(x)はCTFEの場合と同じように動作します。

基本的に、私はあなたの保証を2つの部分に分解したと思います-1つは、安全なconst fnがCTFEがサポートしていないこと（stdinからの読み取り、ポインターの最下位バイトが0かどうかの判断など）を決して試みないことを保証します。 1つは、CTFEがサポートするものがすべてランタイムと一致することを保証するものです。

これらの段落は私の耳に聞こえる音楽です！ 心これは決定論（「純度」）を確実にするように見えますか？ まさに私が以前に考えていたものです。 constの安全性も素晴らしい用語だと思います！

よろしくお願いします。 :)これは、私たちがここで話していることをようやく理解したことを意味します。 「純度」とは色々な意味がありますので、少し不安を感じることがよくあります。 また、決定論はconstの安全性にとって十分な条件ではありません。関連する基準は、CTFEでの実行でエラーが発生するかどうかです。 （deterministc non-const-safe関数の1つの例は、 orcaleに0を掛けたものです。これは、ポインターのバイトを検査するときにmiriがエラーになるため、安全でないコードを使用しても問題ありません。最終的にバイトが重要ではない場合でも、ポインタの最下位バイトを抽出する操作は「const-UB」であるため、安全でないconstコードでも許可されません。）

はい、配列要素の終わりを1つ超えたポインタは、おそらく次の配列要素を指します。 だから何？ それは本当に非決定論的ではありませんか？ とにかく重要なのは、コンパイル時の決定論です。 私の知る限り、ランタイム評価はスタックの枯渇をセグメンテーション違反にする可能性があります。

@RalfJung

このようなシステムのコストは、安全な高階const fnがconst fnクロージャを取得して、クロージャの実行自体が「constsafety」に違反しないことを保証できるようにする必要があることです。 これは、安全なconst fnについて実際に適切な保証を取得するための価格です。

提供される関数が?const fn(T) -> Uである場合にのみ、結果を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!
}

私は1週間かそこらでこの効果（およびそれ以上）に何かを提案するRFCを書きます。

@Centrilこの時点で、エフェクトポリモーフィズムを備えたエフェクトシステムを開発しています。 それが常にあなたの秘密（？）の議題であったことを私は知っています、それが露骨に明白になっていることをあなたに知らせるだけです。^^

@RalfJung昨年、https：//github.com/rust-lang/rfcs/pull/2237で秘密を明かしましたが、書き直さなければなりません;）
今ではほとんどパブリックドメインです^、-

@ SoniEx2

はい、配列要素の終わりを1つ超えたポインタは、おそらく次の配列要素を指します。 だから何？ それは本当に非決定論的ではありませんか？ とにかく重要なのは、コンパイル時の決定論です。 私の知る限り、ランタイム評価はスタックの枯渇をセグメンテーション違反にする可能性があります。

問題は、次のような状況にあります（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に最適化することを望んでいます（そしてそうします！）。 結局のところ、1つのポインターはxを指し、もう1つはyを指しているため、これらが等しくなることはあり得ません。
もちろん、1つのポインタがxの終わりを指しているため、アドレスがマシン上で等しいことを除いて、これはyと同じアドレスです！ したがって、アドレスがどこから来たのかをコンパイラーが認識できないようにコードを十分に不明瞭にすると、比較がtrueと評価されることがわかります。 したがって、C ++標準では、両方の結果を非決定的に発生させることができ、最適化（ false ）とアセンブリへのコンパイル（ true ）の両方が正当化されます。 C標準ではこれが許可されていないため、LLVM（およびGCC）は両方ともこれらの種類の最適化を実行するため、コンパイラーは不適合になります。

私は、このスレッドおよび/またはIRCに関する関連する議論でここに出てきたconstの安全性、constの健全性などの私の考えの要約を書きました： https ：//www.ralfj.de/blog/2018/07/19/

ここでのこの問題は、非常に多くのことが議論されているため、解きほぐすのがやや困難になっています。 @ oli-obkは、const-evalの懸念事項のリポジトリを作成したので、特定のサブ問題について話し合うのに適した場所は、おそらくhttps://github.com/rust-rfcs/const-evalの問題追跡システムです。

@Centrilは、将来の拡張機能と上位互換性のある最小バージョンを安定させることを提案しました。

• 特性の境界を持つ一般的な引数はありません
• fnポインタまたはdyn Trait型の引数または戻り型はありません
  
  
  
  • 引数タイプを再帰的にチェックするため、引数のフィールドもこれらのタイプではない可能性があります
  
  
• 安全でないコードはありません（問題のあるものがあるかどうかわからないため）
  
  
  
  • 個人的には、追加の機能ゲートの背後にすでにあるunionと、生のポインターの参照解除（現在は一般的に禁止されています）を除いて、これで問題ないと思います。 その他の安全でないコードは、他の安全でないconst fnsまたはconst組み込み関数を通過する必要があり、安定化に関する独自の議論が必要です。
  
  

（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 = ...で安全でないことを許可しますが、これにはすべて同じ問題があります。 const fnの本文は、 constの本文とまったく同じようにチェックする必要があると思います。

「unconst」操作（安全であるがconst-safeではない操作（基本的にはrawポインターのすべて））については保守的であり続けたいと思いますが、これらはconstコンテキストではすでに完全に許可されていません。

境界は、constfn自体の一部ではありません。

いいえ、その提案ではimplブロックの境界も許可されません

安全でないコードの問題は何ですか？

コメントに記載されているような問題は見られません。 すべてのconstの安全でない機能/機能は、とにかく独自の安定化を経る必要があります。

@RalfJung問題は、 「 @ Centrilは、何かを見逃したことに神経質になっている。これらは、constコンテキストではすでに完全に許可されていない」と思います。 ;）しかし、ある時点でunsafe { .. }をconst fnで安定させる必要があるので、問題がなく、すべてのunconst操作をキャッチした場合は、それを実行しましょう。

さらに、私たちが何かを逃した場合、人々がconstでそれを使用できるので、私たちはすでに一種の困惑しています。

私はまだconstfnRFCリポジトリのconst安全/プロモーション部分に記入するPRを書く予定です。 それは、私たちがすべてをカバーしたかどうか（そしてテストケースを持っているかどうか）を注意深くチェックする時です。

Discordで思いついたもう1つのことは、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のままにしておきたいとすると、今何かを安定させることは、十分に制限されているので、かなりまともな解決策だと思います（以前はどうして見なかったのですか？！）

これらの断片的な安定化を行うとき、私はただ登録したいだけです
制限とその正当化の明確なリストを要求します。 これは
ユーザーが一見無害な変更を加えてイライラする
コンパイルエラーが発生するので、少なくともエラーを適切にすることができます。 私
推論が多くの議論に広がっていることを認識しますが、そのすべてではありません
私はフォローしましたが、ドキュメント（または
参照、または少なくともノミコン）許可されていない各操作をリストします。
それが引き起こす可能性のある問題、および安定化の見通し（例：「決して」、
「RFCXYZが実装されている場合」、「仕様のこの部分を特定した後」）。

2018年8月20日月曜日午後1時44分Eduard-MihaiBurtescu<
[email protected]>は次のように書いています：

キーワード形式をconstfnのままにしておきたいとすると、安定していると思います
十分に制限されている今の何かは、かなりまともな解決策です（どのように
今まで見たことがなかったの？！）

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/rust-lang/rust/issues/24111#issuecomment-414403036 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAC3n80yVxIa3agsJP4wXZFkgyHVmAsjks5uSvWXgaJpZM4D66IA
。

@ est31 @rkruppeがすでに書いたように、これらのヒューズは-ffast-mathなしで実行するのは違法であり、LLVMはそれを正しく処理すると思います。

私が覚えていることから、基本的な算術はそれほど問題ではありませんが（32ビットx86を除いてx87 ...）、超越関数は問題があります。 そして、それらはconst fnではありませんよね？ ですから、最終的には、この点でもconstのアイテム、プロモーション、 const fnの間で同等になることを願っています。

@RalfJungたとえば、こぼしてから、いくつかの操作の間にFPUレジスタにロードして戻すと、こぼさずに同じ計算と同じ結果が得られるとはまだ確信していません。

私が覚えていることから、基本的な算術はそれほど問題ではありませんが（32ビットx86を除いてx87 ...）、超越関数は問題があります。

超越関数はどのように問題を意味しますか？

IIRC、一部の超越関数は一般的なx86プロセッサでサポートされていますが、これらの関数は低速で回避されており、完全性と既存の実装との互換性のためにのみ含まれています。 したがって、ほとんどすべての場所で、超越関数は基本的な算術関数の組み合わせで表現されます。 これは、それらの参照透過性と算術関数の参照透過性に違いがないことを意味します。 基本的な機能が「安全」である場合、超越関数を含め、それらに基づいて構築されたものはすべてです。 ここでの「参照の不透明性」の唯一の原因は、これらの基本的な算術関数に関するこれらの超越関数の異なる近似（実装）である可能性があります。 それが問題の原因ですか？

@ est31ほとんどの超越関数は、最終的にはプリミティブ整数と浮動小数点演算で構成される単なるライブラリコードですが、これらの実装は標準化されておらず、実際には、Rustプログラムは、その存続期間を通じておそらく3つの異なる実装と対話でき、その一部はホストまたはターゲットによっても異なります。プラットホーム：

• プログラムがターゲットで使用するランタイム実装があります（たとえば、ターゲットプラットフォームのlibm、または状況によってはハードウェア命令）
• LLVMが使用する定数フォルダーがあります（明らかにこれは単なるホストプラットフォームC libmです）
• MIRIがこれらの操作で行うことは何でもあります（たとえば、 rustc_apfloatの何か、またはhttps://github.com/japaric/libm/などのRust実装の解釈）

これらのいずれかが互いに一致しない場合、式が評価されるタイミングに応じて異なる結果を得ることができます。

@rfcbotキャンセル

近い将来、フルモンティが安定する可能性は低いです。
代わりに、短期的に安定できることを願って、より最小限のサブセット（https://github.com/rust-lang/rust/issues/24111#issuecomment-414310119で大まかに概説されている）のコンセンサスを作成したいと思います。 。
このサブセットは＃53555で追跡されます。 詳細については、こちらをご覧ください。

@Centrilの提案はキャンセルされました。

@rkruppe超越関数をllvm組み込み関数に下げる理由はありますか？ 私たちが管理し、すべてのプラットフォームで同じである、よく知られた、錆びない実装にそれらを下げることによって、問題全体を回避することはできませんか？

超越関数をllvm組み込み関数に下げる理由はありますか？

クロスプラットフォームlibm全体を実装しないという単純さに加えて、組み込み関数には、通常のライブラリ関数では得られないLLVMのオプティマイザーとcodegenの利点があります。 明らかに、定数畳み込み（および値の範囲分析などの関連するもの）はこのコンテキストでは問題ですが、それ以外の場合は非常に便利です。 代数的IDもあります（SimplifyLibCallsパスによって適用されます）。 最後に、いくつかの関数（主にsqrtとその逆数であり、超越的ではありませんが、何でも）は、SSEを使用してx86でsqrtssを生成するための特別なコード生成をサポートしています。

私たちが管理し、すべてのプラットフォームで同じである、よく知られた、錆びない実装にそれらを下げることによって、問題全体を回避することはできませんか？

上記のすべてを無視しても、これは優れたオプションIMOではありません。 ターゲットプラットフォームにClibmがある場合、それがより最適化されているか、肥大化を回避するために、それを使用できるはずです。

組み込み関数は、LLVMのオプティマイザーとcodegenで、通常のライブラリ関数では得られない利点があります。

このような最適化は、高速計算がオンになっている場合にのみ有効になると思いましたか？

ターゲットプラットフォームにClibmがある場合、それがより最適化されているか、肥大化を回避するために、それを使用できるはずです。

もちろん。 コンパイルされたバイナリまたはより小さなバイナリの速度の向上など、より重要なものを優先して、このかなりアカデミックなプロパティ（参照透過性）を交換するオプションが常にあるはずです。 たとえば、プラットフォーム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として注釈されていることをコンパイラが伝えると考えることができる2つのケースはそのような関数がパラメータとして&mutを受け取る場合、または他の非const関数を呼び出す場合、コンパイルに失敗します。 したがって、 const fnの実装を変更し、それらの制約を破ると、コンパイラーは停止します。 次に、（a）個別の関数にconst以外のビットを実装するか、意図した変更である場合はAPIを中断するかを選択できます。

私がまだ議論していない別の中間点があり、明示的に設定されていない場合、このマーカーの反対とある種の「関数純度推論」を導入する可能性があります。 次に、ドキュメントには実際のマーカーが表示されますが、 constの場合、そのマーカーの安定性を保証しないことについての警告が表示されます。 問題は、これが怠惰になり、ほぼ毎回これを行うことを奨励する可能性があることですが、それはその目的ではありません。

const fnは出力を生成できる必要がありますか？ なぜ&mutを禁止する必要があるのですか？

@aledomu私のコメントは@AGaussmanに向けられました。 私は、ライブラリの作成者がconstではない関数を公開している場合について話しています（const-nessはAPIの一部であることが意図されていないという点で）。 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

他の問題によってまだ追跡されていない他の領域がある場合は、それについて議論する必要があります。 constevalと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はすべて、プライベートフィールドを持つ型の簡単なコンストラクターです。前者のメッセージは、 Cloneがコンストラクターで使用されていなくても、 struct Guard<T: Clone + Copy>のコンストラクターにあります。後者は、 Option<fn()> （簡略化）をNoneまたはSome(name_of_a_function_item)のいずれかに初期化するためのものです。）

ただし、この問題の説明では、特性も関数ポインタ型も言及されていません。

上記について、さらに2つの具体的な問題があるべきだという意味ではありません。 つまり、 const_fn機能ゲート（エラーメッセージでまだここを指している）の背後にあるすべてのものに追跡の問題があることを何らかの方法で確認するまで、これを再度開く必要があります。 または、 const_fnが完全に安定するまで。

@SimonSapin

メタトラッキングの問題がより具体的な問題で完全にカバーされていることがまったく明確でない場合、メタトラッキングの問題を閉じることは適切ではないと思います。

この問題にはhttps://github.com/rust-lang/rust/issues/34511のフレーバーがあります。これは、追跡の問題に関する限り、最大の混乱の1つです。 この問題もしばらくの間無料で提供されているため、現時点ではメタ問題として機能していません。 このような無料の場合は、代わりにhttp://internals.rust-lang.org/を使用してください。

ただし、この問題の説明では、特性も関数ポインタ型も言及されていません。

上記について、さらに2つの具体的な問題があるべきだという意味ではありません。

それはまさに私がすべきだと思うことです。 T-Langトリアージの観点からは、ターゲットを絞った実用的な問題があることが有利です。

つまり、 const_fn機能ゲート（エラーメッセージでまだここを指している）の背後にあるすべてのものに追跡の問題があることを何らかの方法で確認するまで、これを再度開く必要があります。 または、 const_fnが完全に安定するまで。

const_fnゲートが何を構成しているのか、またはある時点ですべてが安定するのか、私にはわかりません。 元のRFCの境界と関数ポインタ以外のすべてには、未解決の問題があり、次にいくつかの問題があります。

機能ゲートが何を構成しているのか、私にはわかりません。

だからこそ、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]
書きました：

@phanschhttps ://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 ：毎晩何かが閉じられ、解像度がまだ安定していない可能性のあるウィンドウが常にあります。 それはどのように侮辱的ですか？

私はここでコメントすることに抵抗してきました、そして多分私たちはこの会話を内部のスレッドに移すべきです（すでに1つありますか？）しかし...

これを閉じるという決定は私には意味がありません。 これは、コンパイラからのエラーメッセージに表示されるため、追跡の問題であり、それだけではありません。その他の例については、次の投稿を参照してください： https ://internals.rust-lang.org/t/psa-tracking-for-gated

率直に言って、これを閉じるための議論はわかりません...より的を絞った問題が存在することをうれしく思います。そのため、実装を進めることができ、新しい議論と焦点を当てることができますが、コンパイラを関連付ける明確な方法がわかりません。それらとのメッセージ。

繰り返しますが、これが内部のスレッドを必要とする（またはすでに持っている）場合は、この会話をそこに移動しましょう？

編集：それとも、本が古くなっているというだけの問題ですか？ RFCの例を試してみると（いくつかの#[derive(...)]が欠落しています）、Rustrustc1.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を使用できるようにするには、コンパイラを更新する必要があります。