宣言的または手続き的な場合、Dは「静的」ですか？

Question

宣言的または手続き的な場合、Dは「静的」ですか？

次のコードを考えてみましょう：

static if (!is(MyStruct))
{
    struct MyStruct
    {
    }
}

static if (is(MyStruct))
{
    static assert(0);
}

私の最初の理解は、宣言の順序（グローバルスコープ内）は重要ではありません。

しかし、この場合、 static if の順序は、プログラムがコンパイルされるかどうかの違いになります。

したがって、Dのコンパイル時の評価段階は、手続き的な機能（C/C ++のような）、宣言的な機能、または何か他のものですか？それは現在何ですか、そしてそれは何が計画されていますか（両者が異なる場合）？

編集：

私はちょうど、問題はここで終わらないことに気づいた。 .tupleof を使用して現在のモジュールのメンバーを列挙し、同じタイプの問題を作成する場合、静的

5

追加された 28 10月 2011 〜で 09:30 著者 Mehrdad 編集された 22 8月 2012 〜で 08:49

ビュー: 12

源

ro ru fr es pt de hi bn ar uk

2 答え

実装の副作用として手続き型のプロパティを持つ宣言的な機能です。

2

追加された 28 10月 2011 〜で 09:46 著者 FeepingCreature

源

私は、このサンプルコードを違法にするという話があったと思います。それを完全に拒否するか、または未定義の動作を宣言してください。

追加された 28 10月 2011 〜で 01:21, 著者 BCS, 源

@Mehrdad必ずしもそうではない、特に一般的なケースでは。 1つのアプローチは、シンボルテーブルの is（） "ブービートラップ"で、の場合は既に評価された staticの値を変更する記号を挿入することです>



追加された 28 10月 2011 〜で 02:54, 
著者 BCS, 

源

@Mehrdad：別のモジュールでは無関係なので、OPのコードはこの点を示しています：第2の が最初に実行され、何もせず、

トラップ "シンボル MyStruct を実行し、トラップをトリッピングしてエラーメッセージを追加しようとします。それ以外の場合は、 if の2番目のコードにアクセスすることなく、同じエラーメッセージが表示されます。 - OTOHこれは、問題の最も有用なバージョンを違法にすることによって機能します。

追加された 28 10月 2011 〜で 08:20, 著者 BCS, 源

@Mehrdad：複数のモジュールから定義された（完全ではない）シンボルを使用しようとするとエラーが発生するため、モジュール間干渉が既に存在します。私はその場合の解決策は static import かそのようなものだと思います。

追加された 28 10月 2011 〜で 11:47, 著者 BCS, 源

@Mehrdadブービートラップは、 if からどれくらい離れていても、 static if で条件の評価中に行われるすべてのシンボル検索で設定されます。

追加された 31 10月 2011 〜で 05:40, 著者 BCS, 源

@BCS：それは不可能ではないのですか？少なくともミックスインが場に出ると、それは停止問題のように見えます....

追加された 28 10月 2011 〜で 02:10, 著者 Mehrdad, 源

@BCS：2つのモジュールが相互依存関係にあり、それぞれが互いのタイプをチェックした場合、それはどのように正しく動作しますか？どちらが最初ですか？それが重要なのでしょうか？他のコンパイルをブロックすることはできますか？

追加された 28 10月 2011 〜で 06:25, 著者 Mehrdad, 源

@Mehrdad：笑、私はOP自身です。：Pはい、私たちは同じことを言っています - 同じモジュール内にあることは問題に無関係です。それが私の主張です。問題はいずれかの方法で発生します。しかし、問題は、衝突のせいでモジュール全体が別のモジュールからコンパイルされるのを防ぐことができるということです。多分それは私だけですが、idk ...

追加された 28 10月 2011 〜で 10:55, 著者 Mehrdad, 源

@code：{type}（{MyStruct a;}）で is（MyStruct）をバイパスすることができます。）または任意に複雑なもの。コンパイラはこれをすべて把握できますか？

追加された 31 10月 2011 〜で 02:37, 著者 Mehrdad, 源

著者 Jonathan M Davis · Answer 1 · 2011-10-28T06:14Z

それは複雑になる。基本的には宣言的ですが、新しいシンボルを導入する static の場合でも順序は重要です。それ以外にも、それは重要ではないと思いますが、あなたの例が示すように、 static if と新しい static if それは間違いなく問題ありません。

最近の方法については、いくつかの議論があります可能な限り一貫性があり、直感的です。したがって、コーナーケースの場合、特に状況は近い将来変更される可能性があります。しかし、私は、あなたの例が静的アサートをトリガーし続けることを期待しています。問題は、 static if ブロックの順序を逆にすると static assert をトリガーするかどうかです。コンパイラのニュースグループでの議論は完全に決定的で、IMHOに従うのが少し難しいので、私は確かに言うことができません。しかし、新しいシンボルを導入する static if ブロックを伴う少なくともいくつかのケースでは、順序は重要であると思います。

編集：

これは、dmdの主要貢献者の1人が最近投稿しました。

現在、コンパイル時の評価の順番は定義されていません。 DMD   現在、それは字句的な順序では漠然としていますが、それは   近い将来に変化する。 'static if'と 'mixin'が評価されます   字句順に、何か他のことが行われる前に。その後、   それ以外のものはオンデマンドで評価されます。

静的if/mixinパスとは別に、コンパイルは   並列（現在の実装ではこれをまだ行っていませんが）   順序がないことを意味します（複数の項目がコンパイルを完了することがあります   同時に）。

だから、うまくいけば事を明確にする。