function.dd

Ddoc

$(SPEC_S 関数,

$(GRAMMAR
$(GNAME FunctionBody):
    $(GLINK2 statement, BlockStatement)
    $(GLINK BodyStatement)
    $(GLINK InStatement) $(GLINK BodyStatement)
    $(GLINK OutStatement) $(GLINK BodyStatement)
    $(GLINK InStatement) $(GLINK OutStatement) $(GLINK BodyStatement)
    $(GLINK OutStatement) $(GLINK InStatement) $(GLINK BodyStatement)

$(GNAME InStatement):
    $(B in) $(GLINK2 statement, BlockStatement)

$(GNAME OutStatement):
    $(B out) $(GLINK2 statement, BlockStatement)
    $(B out) $(B $(LPAREN)) $(I Identifier) $(B $(RPAREN)) $(GLINK2 statement, BlockStatement)

$(GNAME BodyStatement):
    $(B body) $(GLINK2 statement, BlockStatement)
)


<h3>関数の返値</h3>

        $(P 関数の返値は右辺値とみなされます。
	つまり、返値を他の関数に参照渡しすることはできません。
        )

<h3>本体なしの関数</h3>

	$(P 本体なしの関数)

---
int foo();
---

	$(P で $(D abstract) と宣言されていないものは、どこか他に実装があり、
	リンク時に提供されるものと仮定されます。
	これによって、ユーザーから関数の実装を完全に隠すことや、
	C やアセンブラなど別言語での実装を使うことができます。
	)

$(V2
<h3>$(LNAME2 pure-functions, pure関数)</h3>

        $(P pure 関数は、
		グローバルやstaticの記憶域への書き換えアクセスができず、状態を保存しない関数です。これによって、
        渡されたもの以外何も書き換えないことが保証されることを利用した最適化が可能になります。
        さらに、コンパイラが pure 関数がその引数を置き換えないと保証できる場合、
        完全な、関数としての純粋性 (つまり、
        同じ引数に対して常に同じ結果を返す関数であるという保証) が得られます。
		そのために、pure関数は以下を満たす必要があります:
        )

        $(UL
        $(LI グローバル や static の mutable な状態を読み書きしない)
        $(LI pure関数はpureでない関数を呼び出すことはできません)
        $(LI pure関数によるpureでない関数のオーバーライドはできますが、
	逆はできません。)
        $(LI pureでない関数に対し共変です)
        $(LI I/Oは行えません)
        )

        $(P 実用性を考慮して、pure関数では:)

        $(UL
        $(LI メモリを $(GLINK2 expression, NewExpression) で割り当てられます)
        $(LI プログラムを終了できます)
        $(LI 浮動小数点数の例外フラグを読み書きできます)
        $(LI 浮動小数点数のモードフラグは、
	関数を抜けるときに元の状態に戻すことが保証されている限り、読み書きできます。)
        $(LI $(GLINK2 version, DebugCondition) で制御された
        $(GLINK2 version, ConditionalStatement) の中では、
		pure でない操作を行えます。)
        )

        $(P pure関数は例外を投げることができます。)

---
import std.stdio;
int x;
immutable int y;
const int* pz;

pure int foo(int i,
             char* p,
             const char* q,
             immutable int* s)
{
  debug writeln("in foo()"); // ok, debug文の中ではpureでない関数も可
  x = i;   // エラー。グローバル状態を書き換えている
  i = x;   // エラー。mutableなグローバル状態を読み取っている
  i = y;   // ok。immutableなグローバル状態の読み取り
  i = *pz; // エラー。constなグローバル状態を読み取っている
  return i;
}
---


<h3>$(LNAME2 nothrow-functions, nothrow関数)</h3>

        $(P nothrow関数は、
	クラス $(I Exception) から派生した例外を一切投げない関数です。
        )

        $(P nothrow関数はそうでない関数に対して共変です。)

<h3>$(LNAME2 ref-functions, ref関数)</h3>

        $(P ref関数は、返値を参照で返します。
	ref引数の返値バージョンです。
        )

---
ref int foo() {
  auto p = new int;
  return *p;
}
...
foo() = 3;  // ref返値は左辺値となる
---

<h3>$(LNAME2 auto-functions, auto 関数)</h3>

        $(P auto関数は、関数定義にある
        $(GLINK2 statement, ReturnStatement)
        から返値の型を推論します。
        )

        $(P auto 関数は返値型なしで宣言されます。
	他に特に記憶域クラスのない関数では、
        $(D_KEYWORD auto) 記憶域クラスを指定します。
        )

        $(P 複数の $(I ReturnStatement) がある場合は、
        それらの型は完全にマッチしなければいけません。$(I ReturnStatement) がない場合は、
        返値型は $(D_KEYWORD void) と推論されます。
        )

---
auto foo(int i) {
  return i + 3;  // 返値型はintと推論される
}
---

$(V2
<h3>$(LNAME2 auto-ref-functions, auto ref 関数)</h3>

        $(P auto ref 関数は、
        $(LINK2 #auto-functions, auto 関数) と同様に関数の返値型を推論します。
		加えて、return される式が左辺値であった場合、
		自動的に $(LINK2 #ref-functions, ref 関数)
        となります。ただし、値引数やローカル変数への参照を返すようにはなりません。
        )

---
auto ref foo(int x)     { return x; }  // 値をreturn
auto ref foo()          { return 3; }  // 値をreturn
auto ref foo(ref int x) { return x; }  // refをreturn
auto ref foo(out int x) { return x; }  // refをreturn
auto ref foo() { static int x; return x; }  // refをreturn
---

        $(P 字句的に最初の $(GLINK2 statement, ReturnStatement)
	が関数のref性を決めます:
        )

---
auto ref foo(ref int x) { return 3; return x; }  // ok, 値return
auto ref foo(ref int x) { return x; return 3; }  // エラー。3は左辺値でない。
---
)

$(V2
<h3>$(LNAME2 inout-functions, inout 関数)</h3>

        $(P mutable, const, immutable のどれに対しても同じように適用したい関数を扱う場合、
	その型を返値に伝搬させたいケースが多くあります。
        )

---
int[] foo(int[] a, int x, int y) { return a[x .. y]; }

const(int)[] foo(const(int)[] a, int x, int y) { return a[x .. y]; }

immutable(int)[] foo(immutable(int)[] a, int x, int y) { return a[x .. y]; }
---

        $(P これらの関数から生成されるコードは完全に一致します。
	これらを一つの関数にまとめるには、 $(D_KEYWORD inout)
	型コンストラクタを使います:
        )

---
inout(int)[] foo(inout(int)[] a, int x, int y) { return a[x .. y]; }
---

        $(P $(D_KEYWORD inout) は、
	mutable, const, immutable のいずれかにマッチするワイルドカードとして働きます。
	関数が呼ばれたときに、返値型の inout は、
	引数の mutable, const, immutable
	に合わせて変化します。
        )

        $(P inout 型は const に暗黙変換できますが、他の型になることはありません。
	他の型を暗黙にinoutに変換することもできません。
	inoutへの/からのキャストは @safe 関数では不可能です。
        )

        $(P inout が関数引数リストに現れる場合、
	返値型にも現れなければいけません。
        )

        $(P inout仮引数を持つ関数へと実引数が与えられたとき、以下のケースでマッチしたと判定されます。
	実引数も完全に同じinoutを持つか、または:)

$(OL
        $(LI 実引数がどれもinout型を持たない)
        $(LI 仮引数でinout型となっている部分に、実引数側で mutable, const, immutable
	のいずれかがマッチする。)
)

        $(P このようなマッチがあった場合、全てのマッチがmutableなら、inoutはmutalbeとして扱われます。
	全てのマッチがimmutableなら、inoutはimmutalbeとして扱われます。
	それ以外のケースでは、inoutはconstとして扱われます。
	関数の返値の型は、
	マッチした属性でinoutを置き換えたものとなります。
        )

        $(P グローバルやstaticな変数の型にはinoutを使うことはできません。
        )

        $(P $(B 注:) sharedについて書き忘れたているわけではありません。
	shared型はinoutとはマッチしません。
        )
)

<h3>$(LNAME2 property-functions, プロパティ関数)</h3>

        $(P $(CODE @property) 属性のついた関数が、プロパティ関数です。
	この関数は括弧無しで（つまりプロパティのように）
	呼び出すことができます。
        )

---
struct S {
  int m_x;
  @property {
    int x() { return m_x; }
    int x(int newx) { return m_x = newx; }
  }
}

void foo() {
  S s;
  s.x = 3;   // s.x(int) を呼ぶ
  bar(s.x);  // bar(s.x()) を呼ぶ
}
---
)

<h3>$(LNAME2 virtual-functions, 仮想関数)</h3>

        $(P 仮想関数とは、
	直接呼び出されるのではなく、
	vtbl[] と呼ばれるポインタテーブル経由で間接的に呼び出される関数のことをいいます。
	全ての非staticかつ非privateかつ非templateなメンバ関数は、
	仮想関数です。
	これは非効率的に聞こえるかもしれませんが、
	コード生成時にDはクラス階層を全て把握していますので、
	オーバーライドされていない関数への呼び出しは全て最適化されて
	non-virtual になります。
	C++プログラマは "疑わしきはvirtualにせよ"
	でコードを書く傾向にありますが、
	Dの流儀である "non-virtualにできると証明できない限りvirtualにせよ"
	の方が、結果的には多くの関数を直接呼び出せます。
	オーバーライドしたい関数を
	仮想関数にし忘れる、
	というバグを減らすことにもつながります。
        )

        $(P Dのリンケージを持たない関数はvirtualにはできず、
	それゆえオーバーライドできません。
        )

        $(P メンバテンプレート関数はvirtualにはできず、
	それゆえオーバーライドできません。
        )

        $(P $(D final) という印のついた関数は、
        $(D private) でない限り、
	派生クラスでオーバーライドできません。例えば：
        )

------
class A {
  int def() { ... }
  final int foo() { ... }
  final private int bar() { ... }
  private int abc() { ... }
}

class B : A {
  int def() { ... }  // ok。A.defをオーバーライドする。
  int foo() { ... }  // エラー。A.fooはfinal
  int bar() { ... }  // ok。A.bar は final private だが virtual でない
  int abc() { ... }  // ok。A.abc は virtual でない。B.abc は virtual
}

void test(A a) {
  a.def();    // B.def を呼ぶ
  a.foo();    // A.foo を呼ぶ
  a.bar();    // A.bar を呼ぶ
  a.abc();    // A.abc を呼ぶ
}

void func() {
  B b = new B();
  test(b);
}
------

        $(P 共変の返値型がサポートされています。
	すなわち、派生クラスでオーバーライドした関数では、
	基底クラスでの返値型の
	派生型オブジェクトを返すことができます。
        )

------
class A { }
class B : A { }

class Foo {
  A test() { return null; }
}

class Bar : Foo {
  B test() { return null; } // Foo.test() と共変なオーバーライド
}
------

        $(P 仮想関数は全て隠し引数として
        $(I this) 参照を受け取り、
	これは関数が呼ばれた対象オブジェクトを指しています。
        )

<h3>$(LNAME2 function-inheritance, 関数の継承とオーバーライド)</h3>

	派生クラスの関数で、基底クラスの関数と名前と引数の同じものは、
	基底の関数を上書きします：

------
class A {
  int foo(int x) { ... }
}

class B : A {
  override int foo(int x) { ... }
}

void test() {
  B b = new B();
  bar(b);
}

void bar(A a) {
  a.foo(1);   // B.foo(int) を呼ぶ
}
------

        $(P しかしながら、オーバーロードの解決の際には、
	基底クラスのメンバ関数は考慮されません。
        )

------
class A {
  int foo(int x) { ... }
  int foo(long y) { ... }
}

class B : A {
  override int foo(long x) { ... }
}

void test() {
  B b = new B();
  b.foo(1);  // B.foo(long) を呼ぶ。A.foo(int) は考慮しない
  A a = b;
$(V1    a.foo(1);    // A.foo(int) を呼ぶ)
$(V2    a.foo(1);    // 実行時エラー (A.foo(int) は呼ばれない))
}
------

        $(P オーバーロードの解決の過程で基底クラスの関数も考慮に入れたい場合は、
        $(I AliasDeclaration) を使います：
        )

------
class A {
  int foo(int x) { ... }
  int foo(long y) { ... }
}

class B : A {
  $(B alias A.foo foo;)
  override int foo(long x) { ... }
}

void test() {
  B b = new B();
  bar(b);
}

void bar(A a) {
  a.foo(1);      // A.foo(int) を呼ぶ
  B b = new B();
  b.foo(1);      // A.foo(int) を呼ぶ
}
------

$(V2
        $(P $(I AliasDeclaration) を使わなかった場合、
	派生クラスの関数は、
	例え引数の型が違っていたとしても基底クラスの同名の関数を全てオーバーライドします。
	ただし、
	実際に基底クラスへの参照を通してそれらの引数型違いの関数が実際に呼び出された場合は、
        $(CODE core.exception.HiddenFuncError) 例外が発生します
        )
---
import core.exception;

class A {
   void set(long i) { }
   void $(B set)(int i)  { }
}
class B : A {
   void set(long i) { }
}

void foo(A a) {
  int i;
  try {
    a.$(B set)(3);   // エラー。A.set(int)がBでは定義されていないので
                // 実行時に例外を投げる
  }
  catch ($(B HiddenFuncError) o) {
     i = 1;
  }
  assert(i == 1);
}

void main() {
  foo(new B);
}
---
        $(P 自分のコードを実行してみて $(CODE HiddenFuncError)
        が送出された場合、
        関係するクラスでのオーバーロードやオーバーライドをチェックするようにしましょう。)

        $(P ただし、
		継承階層中の他の全ての仮想関数とオーバーロードに関して排反な場合は、
		$(CODE HiddenFuncError) は投げられません。)
)

        $(P 関数のデフォルト引数値は継承されません：)

------
class A {
  void foo(int $(B x = 5)) { ... }
}

class B : A {
  void foo(int $(B x = 7)) { ... }
}

class C : B {
  void foo(int $(B x)) { ... }
}


void test() {
  A a = new A();
  a.foo();       // A.foo(5) を呼ぶ

  B b = new B();
  b.foo();       // B.foo(7) を呼ぶ

  C c = new C();
  c.foo();       // エラー、C.fooには引数が必要
}
------


<h3>インライン関数</h3>

	inlineという予約語はありません。
	関数をインライン化するかどうかは、
	コンパイラが決定します。Cでの予約語registerに対し、
	実際に変数をレジスタに配置するかどうかはコンパイラにゆだねられているのと
	同様です。（Dにはregisterという予約語もありません。）


<h2>$(LNAME2 function-overloading, 関数オーバーロード)</h2>

        $(P 関数は、仮引数の型と実引数の型がどれだけよくマッチするかという基準によって
	オーバーロードされます。
    $(I もっともよく) マッチする関数が選択されます。
	マッチの適合度は以下の４段階あります：
        )

        $(OL
        $(LI マッチしない)
        $(LI 暗黙変換によるマッチ)
        $(V2 $(LI constへの変換によるマッチ))
        $(LI 正確なマッチ)
        )

        $(P 実引数それぞれ ($(CODE this) ポインタも含む) が
	関数の対応する仮引数と比較され、
	その実引数に関するマッチ適合度が決定されます。
    引数のうち$(I 一番悪い)もののマッチ適合度が、
	関数全体としてのマッチ適合度と定義されます。)

$(V2
        $(P リテラルは $(CODE ref) や $(CODE out) 引数とはマッチしません)
)
$(V1
        $(P 複数の関数が同じマッチ適合度にある場合、
        曖昧でエラーとなります。
        )
)
$(V2
        $(P 複数の関数が同じマッチ適合度にある場合、
        $(LNAME2 partial-ordering, $(I partial ordering))
        iによって最適なマッチが決定されます。
	Partial ordering では、もっとも特殊化された関数が選択されます。
	他と比べてより特殊化されていると言える関数が無い場合、
	曖昧な関数呼び出しとしてエラーになります。
        関数 $(CODE f()) と
        $(CODE g()) の partial ordering は、まず $(CODE f()) の引数型を取り出し、
		それぞれの型のデフォルト値によって
        $(CODE g()) の呼び出しの型チェックを試みることで判定されます。
        成功すれば、$(CODE f()) は少なくとも
        $(CODE g()) と同等以上に特殊化されていることになります。
        例えば:
        )
---
class A { }
class B : A { }
class C : B { }
void foo(A);
void foo(B);

void test() {
  C c;
  /* foo(A) と foo(B) のどちらも暗黙変換によるマッチなので、
   * partial ordering を適用する。
   * foo(B) は引数 A では呼び出せないが、foo(A) は
   * 引数 B で呼び出せる。従って foo(B) の方がより特殊化されていることになり、選択される。
   */
  foo(c); // foo(B) を呼び出す
}
---
        $(P 可変個引数関数は、
	そうでない関数よりも特殊化の度合いが低いと見なされます。
        )
)

        $(P D
	のリンケージを持たない関数はオーバーロードできません。
	名前マングリングが引数の型を考慮していないためです。
        )

$(V2
<h2><a name="overload-sets">オーバーロード集合</a></h2>

        $(P 同じスコープで宣言された関数同士はお互いオーバーロードしあいます、
	このような関数のあつまりを $(I オーバーロード集合) と呼びます。
	典型的な例は、
	モジュールレベルで定義された関数によるオーバーロード集合です:
        )

---
module A;
void foo() { }
void foo(long i) { }
---

        $(P $(CODE A.foo()) と $(CODE A.foo(long)) がオーバーロード集合を形成します。
	別のモジュールで同名の関数を宣言することも可能で:
        )

---
module B;
class C { }
void foo(C) { }
void foo(int i) { }
---

        $(P さらに別のモジュール C で A と B を同時に import しても構いません。
	C では二つのオーバーロード集合、つまり $(CODE A.foo) oのオーバーロード集合と $(CODE B.foo)
        oのオーバーロード集合が存在することになります。そして、ちょうど１個のオーバーロード集合に
	マッチした場合のみ、実際に呼び出される $(CODE foo) のインスタンスが選択されます。
        )

---
import A;
import B;

void bar(C c) {
  foo();    // A.foo() を呼ぶ
  foo(1L);  // A.foo(long) を呼ぶ
  foo(c);   // B.foo(C) を呼ぶ
  foo(1,2); // エラー。どの foo にもマッチしない
  foo(1);   // エラー。A.foo(long) と B.foo(int) の両方にマッチ
  A.foo(1); // A.foo(long) を呼ぶ
}
---

        $(P $(CODE foo(1)) に対しては $(CODE B.foo(int)) の方が $(CODE
        A.foo(long)) よりも適合度は高いですが、
	違う２つのオーバーロード集合両方にマッチするので、
	これはエラーとなります。
        )

        $(P alias宣言を使うことで、オーバーロード集合を併合することができます:)

---
import A;
import B;

alias A.foo foo;
alias B.foo foo;

void bar(C c) {
  foo();    // A.foo() を呼ぶ
  foo(1L);  // A.foo(long) を呼ぶ
  foo(c);   // B.foo(C) を呼ぶ
  foo(1,2); // エラー。どの foo にもマッチしない
  foo(1);   // B.foo(int) を呼ぶ
  A.foo(1); // A.foo(long) を呼ぶ
}
---

)


<h3><a name="parameters">関数の引数</a></h3>

$(V1
        $(P 関数引数のには $(B in), $(B out), $(B inout), $(B lazy)が指定できます。
        $(B in) がデフォルトです。そのほかは記憶域クラスのように動作します。
        例:
	)

------
int foo(in int x, out int y, inout int z, int q);
------

        $(P x は $(B in), y は $(B out), z は $(B inout), q は $(B in) です。
        )
)
$(V2
        $(P 関数引数の記憶クラスには $(B in), $(B out),
        $(B ref), $(B lazy), $(B const), $(B immutable), $(B shared),
	$(B inout),
        $(B scope) が指定できます。
        例:
	)
------
int foo(in int x, out int y, ref int z, int q);
------

        $(P x は $(B in), y は $(B out), z は $(B ref), q はそのいずれでもありません。
        )
)

        $(UL
        $(LI 関数宣言にどれが入力でどれが出力か明示することで、
		理解しやすくなります。)
        $(LI IDLを別の言語として用意する必要がなくなります。)
        $(LI コンパイラに多くの情報を与えることで、
		よりよいエラーチェックやコード生成が
		可能になります。)
        )

	$(TABLE2 仮引数の記憶域クラス,
	$(THEAD 記憶域クラス, 説明)
	$(TROW $(I none), 仮引数は実引数の書き換え可能なコピーとなる)
	$(V1 $(TROW $(D in), $(I none) と同じ))
	$(V2 $(TROW $(D in), $(D const scope) と同じ))
	$(TROW $(D out), 仮引数は関数に入る際に、
	その型のデフォルト値で初期化される)
	$(V1 $(TROW $(D inout), 引数は参照渡しされる))
	$(V2 $(TROW $(D ref),   引数は参照渡しされる))
	$(V2 $(TROW $(D scope), 仮引数への参照は関数スコープの外に出すこと
	(グローバル変数への代入など) はできない))
	$(TROW $(D lazy), 実引数は呼び出し側ではなく、呼ばれた関数の中で使った時に評価される)
	$(V2
	$(TROW $(D const), 実引数が暗黙にconst型に変換される)
	$(TROW $(D immutable), 実引数が暗黙にimmutable型に変換される)
	$(TROW $(D shared), 実引数が暗黙にshared型に変換される)
	$(TROW $(D inout), 実引数が暗黙にinout型に変換される)
	)
	)

------
void foo(out int x) {
  // x は int.init、つまり 0 に
  // 関数の最初でセットされる
}

int a = 3;
foo(a);
// a は 0


void abc(out int x) {
  x = 2;
}

int y = 3;
abc(y);
// y は 2


void def($(V1 inout)$(V2 ref) int x) {
  x += 1;
}

int z = 3;
def(z);
// z は 4
------------

        $(P 動的配列やオブジェクト引数は元々参照渡しされますが、
	これらについては、
	in/out/ref は参照に対して適用され、中身には影響しません。
        )

        $(P $(D lazy) 引数は関数が呼び出されるときに評価されるのではなく、
	関数の中で引数が使われる時点で初めて評価されます。このため、
        $(D lazy) 引数は一度も実行されないこともあれば複数回実行される可能性もあります。 $(D lazy)
        引数は左辺値とすることはできません。)

---
void dotimes(int n, lazy void exp) {
  while (n--)
    exp();
}

void test() {
  int x;
  dotimes(3, writefln(x++));
}
---

        $(P 次のように表示されます:)

$(CONSOLE
0
1
2
)

        $(P $(D void) 型の $(D lazy)
        引数は、任意の型の引数を受け付けます。)

<h3>デフォルト引数</h3>

        $(P 関数のパラメタ宣言にはデフォルト値を設定することが可能です:)

---
void foo(int x, int y = 3) {
  ...
}
...
foo(4);   // foo(4, 3); と同じ
---

        $(P デフォルト引数は、
	関数宣言のコンテキストで評価されます。
	引数にデフォルト値を設定する場合、
	それよりも後ろの引数にも全てデフォルト値を設定する必要があります。
        )

<a name="variadic"><h2>可変個関数引数</h2></a>

	引数の個数が定まっていな関数のことを、可変個引数関数と呼びます。
	可変個引数関数には、
	以下の３つの形式があります：

        $(OL
        $(LI Cスタイル可変個引数関数)
        $(LI Dスタイル可変個引数関数)
        $(LI 型安全可変個引数関数)
        )


<h3>Cスタイル可変個引数関数</h3>

        Cスタイル可変個引数関数は、必須の引数の後ろに
	... をつけた形で宣言されます。
	$(D extern (C)) のような、D以外のリンケージを持ちます：

------
extern (C) int foo(int x, int y, ...);

foo(3, 4);      // ok
foo(3, 4, 6.8); // ok, 可変引数が１つ。
foo(2);         // エラー。引数yは必須。
------

	この形式の関数は、最低１つの非変引数を受け取る必要があります。

------
extern (C) int def(...); // エラー、最低一つの引数が必要
------

        $(P
	Cスタイル可変個引数関数は、Cの可変個引数関数の呼び出し規約と一致していて、
    $(D printf) のような
	Cのライブラリ関数を呼び出すのに利用できます。
	)

	$(P 可変個引数へのアクセスは、
	標準ライブラリモジュール $(V1 $(B std.c.stdarg))$(V2 $(B core.stdc.stdarg)) を使います。
	)

------
import $(V1 std.c.stdarg)$(V2 core.stdc.stdarg);

void test() {
  foo(3, 4, 5);   // 可変個引数の先頭は、5
}

int foo(int x, int y, ...) {

  va_list ap;
  version (X86_64)
    va_start(ap, __va_argsave);
  else version (X86)
    va_start(ap, y);  // y は最後の名前付きメンバ

  int z;
  va_arg(ap, z);  // z は 5 になる

  va_end(ap);
}
------


<h3>Dスタイル可変個引数関数</h3>

	型情報付き可変個引数関数は、必須の引数の後ろに
	... をつけた形で宣言します。
	この種類の関数はDリンケージを持ち、
	固定の引数が一個もなくても構いません：

------
int abc(char c, ...);   // 必須引数が一つ: c
int def(...);           // ok
------

	引数にアクセスするには、以下の import が必要です:

------
import $(V1 std.stdarg)$(V2 core.vararg);
------

        可変個引数関数の中では、
        $(V1 $(D std.stdarg.va_list))$(V2 $(D core.vararg)) で参照できる
	特別なローカル変数 $(B _argptr)
	が使えます。
        引数にアクセスするには、$(B _argptr) を
		$(D va_arg) と合わせて使います。

------
import $(V1 std.stdarg)$(V2 core.vararg);

void test() {
  foo(3, 4, 5);   // 可変個引数の先頭は、5
}

int foo(int x, int y, ...) {

  int z;

  z = va_arg!int(_argptr); // z に 5 が入る
}
------

        Dのリンケージを持つ可変個引数関数には、さらに $(D TypeInfo[])
        型の隠れた引数 $(B _arguments) が渡されます。
        $(B _arguments) によって、
	実際に渡された引数の個数とそれぞれ型がわかります。
	この情報を元に、型安全な可変個引数関数を作ることができます。

------
import std.stdio;
import $(V1 std.stdarg)$(V2 core.vararg);

class Foo { int x = 3; }
class Bar { long y = 4; }

void printargs(int x, ...) {
  writefln("%d arguments", $(B _arguments).length);
  for (int i = 0; i < $(B _arguments).length; i++)
  {
    $(V1 $(B _arguments)[i].print();)$(V2 writeln($(B _arguments)[i]);)

    if ($(B _arguments)[i] == typeid(int))
    {
      int j = va_arg!(int)(_argptr);
      writefln("\t%d", j);
    }
    else if ($(B _arguments)[i] == typeid(long))
    {
      long j = va_arg!(long)(_argptr);
      writefln("\t%d", j);
    }
    else if ($(B _arguments)[i] == typeid(double))
    {
      double d = va_arg!(double)(_argptr);
      writefln("\t%g", d);
    }
    else if ($(B _arguments)[i] == typeid(Foo))
    {
      Foo f = va_arg!(Foo)(_argptr);
      writefln("\t%s", f);
    }
    else if ($(B _arguments)[i] == typeid(Bar))
    {
      Bar b = va_arg!(Bar)(_argptr);
      writefln("\t%s", b);
    }
    else
      assert(0);
  }
}

void main() {
  Foo f = new Foo();
  Bar b = new Bar();

  writefln("%s", f);
  printargs(1, 2, 3L, 4.5, f, b);
}
------

        これは次のように表示されます：

------
00870FE0
5 arguments
int
        2
long
        3
double
        4.5
Foo
        00870FE0
Bar
        00870FD0
------


<h3>型安全可変個引数関数</h3>

	型安全可変個引数関数は、
	引数の可変部分が配列やクラスオブジェクトの生成に使われる、
	という形で実現されています。
        <p>

	配列として可変部分を受け取る場合：

------
int test() {
  return sum(1, 2, 3) + sum(); // 6+0 を返す
}

int func() {
  int[3] ii = [4, 5, 6];
  return sum(ii);             // 15を返す
}

int sum(int[] ar ...) {
  int s;
  foreach (int x; ar)
    s += x;
  return s;
}
------

       静的配列の場合：

------
int test() {
  return sum(2, 3);   // エラー。配列に3個の値が必要
  return sum(1, 2, 3); //  6を返す
}

int func() {
  int[3] ii = [4, 5, 6];
  int[] jj = ii;
  return sum(ii); // 15を返す
  return sum(jj); // エラー、型の不一致
}

int sum(int[3] ar ...) {
  int s;
  foreach (int x; ar)
    s += x;
  return s;
}
------

	クラスオブジェクトの場合：

------
class Foo {
  int x;
  string s;

  this(int x, string s) {
    this.x = x;
    this.s = s;
  }
}

void test(int x, Foo f ...);

...

Foo g = new Foo(3, "abc");
test(1, g);         // ok, gはFooのインスタンス
test(1, 4, "def");  // ok
test(1, 5);         // エラー、Fooのコンストラクタでマッチするものがない
------

	実装は、オブジェクトや配列のインスタンスをスタック上に作ることができます。
	ということは、可変個引数関数からreturnした後にそのインスタンスを参照すると、
	エラーになります：

------
Foo test(Foo f ...) {
  return f;   // エラー。インスタンスfの内容はreturnのあと無効になる
}

int[] test(int[] a ...) {
  return a;       // エラー。returnの後は配列の内容は無効
  return a[0..1]; // エラー。returnの後は配列の内容は無効
  return a.dup;   // ok, コピーが作られている
}
------

	その他の型の場合、引数はその型そのものになります：

------
int test(int i ...) {
  return i;
}

...
test(3);    // 3を返す
test(3, 4); // エラー、引数が多すぎる
int[] x;
test(x);    // エラー。型の不一致
------

<h3>遅延可変個引数</h3>

        $(P 可変個引数の型が、
	引数を持たないdelegateの配列であった場合:
        )

---
void foo(int delegate()[] dgs ...);
---

        $(P delegate型でないような実引数は、
	その型のdelegateへ暗黙変換されます。
        )

---
int delegate() dg;
foo(1, 3+x, dg, cast(int delegate())null);
---

        $(P これは以下と同じです:)

---
foo( { return 1; }, { return 3+x; }, dg, null );
---

<h2>$(LNAME2 Local Variables, ローカル変数)</h2>

        $(P ローカル変数に値を代入する前に使用するのはエラーです。実装は、
	このエラーを必ずしも検出しないかもしれません。
	他の言語のコンパイラはしばしばこの問題に対して警告を出しますが、
	これは常にバグなので、エラーであるべきです。
        )

        $(P 一度も参照されないローカル変数を宣言するのもエラーです。
	古い利用されてないコードに現れるような死んだ変数は、
	メンテナンスプログラマの混乱の元でしかありません。
        )

        $(P 同じ関数内の他の変数の名前を隠すローカル変数は、
	エラーです：
        )

------
void func(int x) {
   int x;     // エラー, xの前の定義を隠している
   double y;
   ...
   { char y;  // エラー, yの前の定義を隠している
     int z;
   }
   { wchar z; // 問題なし, zの前の定義はスコープ外
   }
}
------

        $(P これは不合理に見えるかもしれませんが、実際上は、
	このエラーに該当するのはバグのあるコードか、
	少なくともバグのように見えるコードです。
        )

        $(P ローカル変数のアドレスや参照を返すのは、
	エラーです。
        )

        $(P
		ローカル変数とラベルとに同じ名前を付けるのはエラーです。
        )

<h2>$(LNAME2 Local Static Variables, ローカルstatic変数)</h2>

	$(P 関数内のローカル変数は static
	$(V2 または __gshared) と宣言することができ、
	その場合変数はスタック上ではなく静的に割り当てられます。
	代入された値は関数から一度抜けたあとも保持されるようになります。
	)

---
void foo() {
  static int n;
  if (++n == 100)
    writeln("called 100 times");
}
---

	$(P static 変数の初期値はコンパイル時評価可能である必要があり、
	この初期化はスレッドの開始時
	$(V2 (あるいは __gshared に関してはプログラム開始時) に行われます。
	ローカル static
	変数に対する静的コンストラクタや静的デストラクタはありません。)
	)

	$(P static変数の可視性は通常のスコープ規則に従いますが、
	その名前は関数内で一意でなければいけません。
	)

---
void main() {
  { static int x; }
  { static int x; } // エラー
  { int i; }
  { int i; } // ok
}
---

<h2><a name="nested">ネスト関数</a></h2>

        $(P 他の関数の内部にネストして関数を書くことができます:)

------
int bar(int a) {
  int foo(int b) {
    int abc() { return 1; }

    return b + abc();
  }
  return foo(a);
}

void test() {
  int i = bar(3); // i に 4 が代入される
}
------

        $(P ネスト関数は、その名前がスコープにある範囲からのみ参照できます。)

------
void foo()
{
  void A()
  {
    B(); // エラー。Bは前方参照
    C(); // エラー。Cは未定義
  }
  void B()
  {
    A(); // ok, スコープ内
    void C()
    {
      void D()
      {
        A();      // ok
        B();      // ok
        C();      // ok
        D();      // ok
      }
    }
  }
  A(); // ok
  B(); // ok
  C(); // エラー。C は未定義
}
------

        $(P そして:)

------
int bar(int a) {
  int foo(int b) { return b + 1; }
  int abc(int b) { return foo(b); }   // ok
  return foo(a);
}

void test() {
  int i = bar(3);     // ok
  int j = bar.foo(3); // エラー。bar.foo はここから見えない
}
------

        $(P ネスト関数は外側の関数の変数や、
	その他のシンボルにアクセスできます。
	読み書き双方のアクセスが可能です。
        )

------
int bar(int a) {
  int c = 3;

  int foo(int b) {
    b += c;       // 4 が b に足される
    c++;          // bar.c は 5 になる
    return b + c; // 返値は 12
  }
  c = 4;
  int i = foo(a); // i は 12
  return i + c;   // 17 を返す
}

void test() {
  int i = bar(3); // i に 17 が代入される
}
------

        $(P このアクセスは、ネストの階層が複数段でも構いません：)

------
int bar(int a) {
  int c = 3;

  int foo(int b) {
      int abc() {
          return c;   // bar.c にアクセス
      }
      return b + c + abc();
  }
  return foo(3);
}
------

        $(P staticなネストした関数は、外側の関数のスタック変数を触ることができず、
	static変数だけにアクセスできます。
	これはstaticメンバ関数のふるまいとよく似ています。
        )

------
int bar(int a) {
  int c;
  static int d;

  static int foo(int b) {
    b = d;          // ok
    b = c;          // エラー。foo() は bar() のスタックフレームにアクセスできない
    return b + 1;
  }
  return foo(a);
}
------

        $(P 関数は、メンバ関数の中にもネストできます：)

------
struct Foo {
  int a;

  int bar() {
    int c;

    int foo() {
      return c + a;
    }
    return 0;
  }
}
------
$(V1
        $(P メンバ関数の中にネストしたクラスや構造体からは、
	外側の関数のスタック変数にはアクセスできませんが、
	その他のシンボルにはアクセス可能です：
        )

------
void test() {
  int j;
  static int s;

  struct Foo {
    int a;

    int bar() {
      int c = s;  // ok, s は static
      int d = j;  // エラー。test() のスタックフレームにはアクセス不可

      int foo() {
        int e = s;    // ok, s は static
        int f = j;    // エラー。test() のスタックフレームにはアクセス不可
        return c + a; // ok, bar() のフレームにはアクセス可能
                      // 従って、Foo.bar() の 'this' ポインタを通して
                      // Fooのメンバにもアクセスできる
      }

      return 0;
    }
  }
}
------
)
        $(P ネストした関数は、常にDの関数リンケージを持ちます。
        )

        $(P モジュールレベルの定義と違い、関数スコープ内での宣言は、
	書かれた順番に処理されます。どういうことかと言うと、
	２つのネストした関数が相互に呼び出し合うことはできません：
        )

------
void test() {
  void foo() { bar(); } // エラー、bar は未定義
  void bar() { foo(); } // ok
}
------

        $(P これは二つの関数をネスト構造体のメンバとして解決する手が一つあります。
		あるいは、delegateを使う方法もあります：)

------
void test() {
  void delegate() fp;
  void foo() { fp(); }
  void bar() { foo(); }
  fp = &bar;
}
------

	$(P ネスト関数はオーバーロードできません。)

<h3><a name="closures">デリゲート, 関数ポインタ, $(V1 動的)クロージャ</a></h3>

        $(P 関数ポインタは、staticなネストした関数を指すことができます：)

------
int function() fp;

void test() {
  static int a = 7;
  static int foo() { return a + 3; }

  fp = &foo;
}

void bar() {
  test();
  int i = fp();       // i は 10 となる
}
------

        $(P delegate では、staticでないネストした関数を指せます：)

------
int delegate() dg;

void test() {
  int a = 7;
  int foo() { return a + 3; }

  dg = &foo;
  int i = dg(); // i は 10 になる
}
------

$(V1
        $(P ただし、
		スタック変数は、その関数が終了したら無効になります。
        スタック変数が関数終了時に無効になるのと同様です。
        )

------
int* bar() {
  int b;
  test();
  int i = dg(); // エラー、test.a はもう存在しない
  return &b;    // エラー、bar.b は bar() の終了後は無効
}
------
)
$(V2
        $(P ネストした関数から参照されているスタック変数は、
	関数が終了した後も有効です（これは D 1.0
	とは異なる仕様です）。これを  $(I クロージャ) といいます。
	ただし、スタック変数のアドレスをreturnするのはクロージャではないため、
	エラーになります。
        )

------
int* bar() {
  int b;
  test();
  int i = dg(); // ok, test.a はクロージャの中にありまだ有効
  return &b;    // エラー、bar.b は bar() の終了後は無効
}
------
)

        $(P 非staticなネストした関数へのdelegateは、
	二つのデータを持ちます。
	それは、外側の関数のスタックフレームを指すポインタ ($(I フレームポインタ)と呼びます) と、
	関数のアドレスです。これは、構造体/クラスの
	非staticメンバ関数へのdelgateが $(I this)
	ポインタとメンバ関数のアドレスから
	なっていることと似ています。どちらのタイプのdelegateも互換性があり、
	実際に、同じ型です：
        )

------
struct Foo {
  int a = 7;
  int bar() { return a; }
}

int foo(int delegate() dg) {
  return dg() + 1;
}

void test() {
  int x = 27;
  int abc() { return x; }
  Foo f;
  int i;

  i = foo(&abc);   // i は 28 になる
  i = foo(&f.bar); // i は 8 になる
}
------

        $(P 環境と関数の組み合わせは、
        a $(I 動的クロージャ) と呼ばれています。
        )

        $(P デリゲートの $(B .ptr) プロパティは、
        $(D void*) 型でフレームポインタの値を返します
        )

        $(P デリゲートの $(B .funcptr) プロパティは、
		function型で関数ポインタの値を返します
        )

        $(P $(B 今後の方向性:) 関数ポインタとdelegateの構文を共通にして、
		相互に互換性を持たせる予定です。
        )

<h3>無名関数・無名デリゲート</h3>

        $(P See $(GLINK2 expression, FunctionLiteral) を参照してください。
        )

<h2>main() 関数</h2>

        $(P コンソールプログラムでは、$(D main()) が実行開始点となります。
	全てのモジュール初期化子が呼ばれ、
	ユニットテストが実行された後に呼び出されます。
	mainから戻った後は、全てのモジュールデストラクタが呼び出されます。
        $(D main()) の宣言は必ず以下のいずれかとします：
        )

----
void main() { ... }
void main(string[] args) { ... }
int main() { ... }
int main(string[] args) { ... }
----

<h2>$(LNAME2 interpretation, コンパイル時関数実行 (CTFE))</h2>

    $(P 関数の一部は、コンパイル時に実行可能です。
	再帰やループが必要なアルゴリズムで生成される定数をたたみ込みたい時に、
	この機能は有用です。
	コンパイル時に実行するためには、関数は以下の条件を満たしている必要があります:
    )

    $(OL
    $(LI 関数のソースコードがコンパイラに見えている必要があります。
        $(D_KEYWORD extern)
        で宣言だけが見えている関数はコンパイル時実行はできません。)

    $(LI 実行される式は、
        グローバル変数やローカルstatic変数には触れません。)

    $(LI $(D_KEYWORD asm) 文は使えません。)

    $(LI 移植性のないキャスト ($(D int[]) から $(D float[]) へのキャストなど)、
        具体的にはエンディアンに依存するキャストなどは、使えません。
        signed と unsigned の間のキャストは可能です。)
    )

    $(P CTFEでは、ポインタは、安全な使用であれば使うことができます:)

    $(UL
        $(LI
		ポインタ算術に関してはC形式の意味論が厳密に強制されます。
        ポインタ算術は静的ないしは動的配列の要素を指すポインタに関してのみ可能です。
        このようなポインタは配列の要素か、
        配列の終端の１つ先だけを指すことができます。
        null ポインタや、配列以外を指しているポインタについては、
        ポインタ算術は完全に禁止となります。
        )

        $(LI
        異なるメモリブロックに属するメモリの配置関係は未定義です。
        ポインタの順序比較 (<, <=, >, >=)
        は同じ配列を指すポインタ間か、または少なくとも一方が
        $(D null) である時のみ可能です。
        )

        $(LI
        独立したメモリブロック間のポインタ比較は、
        そのような比較が
        $(D &&) か $(D ||) を組み合わせて結果がメモリブロック間配置に非依存になっている場合を除き、
        コンパイル時エラーとなります。それぞれの比較は、二つのポインタ式の間でなされ、
        <, <=, >, >= のいずれかで比較したもの、
        $(D ! ) によって否定をつけたものが記述可能です。

        $(P
        例として、 $(D (p1 > q1 && p2 <= q2) ) という式は
        $(D p1) と $(D p2) がメモリブロック
        $(I P) へのポインタとなる式で、$(D q1) と $(D q2) がメモリブロック
        $(I Q) へのポインタとなる式であれば、$(I P) と $(I Q)
        が無関係であっても正統です。
        この式は、$(D [p1..p2]) が $(D [q1..q2]) の内側にあれば true、なければ false を返します。
        同様に $(D (p1 < q1 || p2 > q2) ) という式は
        $(D [p1..p2]) が $(D [q1..q2]) の外側にあるときに true となります。
        )
        )

        $(LI
        等価性比較 (==, !=, $(D_KEYWORD is), $(D_KEYWORD !is))
        は全てのポインタの間で、制限無く使用可能です。
        )

        $(LI
        どんなポインタも $(D void *) へキャストし、また元の型へと $(D void *) 
        からキャストで戻すことができます。
        ポインタと非ポインタの間のキャストは許されません。
        )
    )

    $(P 以上の制限は、実際に実行される式にだけ適用されます。
        例えば:
    )
---
static int y = 0;

int countTen(int x) {
  if (x > 10)
    ++y;
  return x;
}

static assert(countTen(6) == 6); // OK
static assert(countTen(12) == 12);  // 不可、yを変更しようとする
---
$(V2
    $(P bool型の $(D_KEYWORD __ctfe) 擬似変数が提供され、コンパイル時には $(D_KEYWORD true)
        に、実行時には $(D_KEYWORD false) に評価されます。
        これによって、
		コンパイル時には使えない処理を避ける代替実装を選択することなどができます。
    )
)

	$(P 処理をコンパイル時に走らせるには、関数呼び出しが、
	コンパイル時に必ず評価されねばならない文脈に現れるようにします。
	例として:)

	$(UL
	$(LI static変数の初期化)
	$(LI static配列の次元)
	$(LI テンプレートの引数)
	)

---
template eval( A... ) {
  const typeof(A[0]) eval = A[0];
}

int square(int i) {
  return i * i;
}

void foo() {
  static j = square(3);     // コンパイル時
  writefln(j);
  writefln(square(4));      // 実行時
  writefln(eval!(square(5))); // コンパイル時
}
---

    $(P 関数のコンパイル時実行は、
	ランタイム実行よりもかなり時間がかかります。
	関数が無限ループするような場合、実行時ではなく、
	コンパイル時にハングします。
    )

    $(P 修復不可能なエラー ($(D_KEYWORD assert) 失敗など)
    は例外を投げません; かわりに、即座に解釈実行が終了されます。
    )

    $(P コンパイル時実行される関数は、以下のような状況では、
	実行時と異なる値を返すことがあります:
    )

    $(UL

    $(LI 浮動小数点演算が、
	実行時より高い精度で行われる)
    $(LI 実装定義の評価順序に依存している)
    $(LI 未初期化変数の使用)

    )

    $(P これらは、
	最適化の設定が結果に影響を及ぼすのと同じ種類の状況です。)

<h3>文字列ミックスインとコンパイル時間数実行</h3>

        $(P コンパイル時に実行される関数は、実行時にも必ず動作するものでなければいけません。
	コンパイル時の関数実行は、
	必ずしも実行時と同等のものであるとは限りません。
	これは、関数のセマンティクスは関数のコンパイル時の値に依存してはいけない、
	ということを意味しています。例を挙げると:)

---
int foo(char[] s) {
  return mixin(s);
}

const int x = foo("1");
---

        $(P この例は、foo() の実行時コードが生成できないため不正です。
	このようなことをしたい場合は、
	関数テンプレートを使う方が適切でしょう。)

$(V2
<h2>$(LNAME2 function-safety, 関数の安全性)</h2>

        $(P $(I セーフ関数) は、
        $(DPLLINK glossary.html#undefined_behavior, $(I 未定義動作)).
	を決して引き起こさないことが静的にチェックされた関数です。
	未定義動作は、
	しばしば悪意のある攻撃の対象となります。
        )

<h3>$(LNAME2 safe-functions, セーフ関数)</h3>

        $(P $(CODE @safe) 属性のついた関数が、セーフ関数です。)

        $(P セーフ関数の中では、
		以下の操作は禁止されます:)

        $(UL
        $(LI ポインタ型から、$(CODE void*) 以外の他の型へのキャスト)
        $(LI 非ポインタ型からポインタ型へのキャスト)
        $(LI ポインタ値の変更)
        $(LI ポインタと他の型のオーバーラップしたunionへのアクセス
        )
        $(LI システム関数の呼び出し)
        $(LI $(CODE class Exception) 派生でない例外のキャッチ)
        $(LI インラインアセンブラ)
        $(LI mutableからimmutableへの明示キャスト)
        $(LI immutableからmutableへの明示キャスト)
        $(LI スレッドローカルかっらsharedへの明示キャスト)
        $(LI sharedからスレッドローカルへの明示キャスト)
        $(LI ローカル変数や関数引数のアドレス取得)
        $(LI $(D_KEYWORD __gshared) 変数へのアクセス)
        )

        $(P セーフ関数の中にネストした関数は、
	デフォルトでセーフ関数とされます。
        )

        $(P セーフ関数は信頼済み関数やシステム関数に対して共変です。)

        $(P $(B 注:) 検証可能な安全性であるにも関わらず、
	コンパイラや仕様のバグによって、検査しきれていない物があるかもしれません。
	そのようなエラーを見つけたら、修正できるように、ご報告下さい。
        )

<h3>$(LNAME2 trusted-functions, 信頼済み関数)</h3>

        $(P $(CODE @trusted) 属性のついた関数が、信頼済み関数です。)

        $(P 信頼済み関数は、
	セーフ関数から呼ばれた時には未定義動作を決して引き起こさない、とプログラマによって保証された関数です。
	一般に、信頼済み関数は、目で見て安全性を簡単に確認できるように、
	できるだけ小さく留めるべきです。
        )

        $(P 信頼済み関数からは、セーフ・信頼済み・システムのいずれの種類の関数も呼び出せます。
        )

        $(P 信頼済み関数は、セーフ関数やシステム関数に対して共変です。)

<h3>$(LNAME2 system-functions, システム関数)</h3>

        $(P $(CODE @safe) も
        $(CODE @trusted) もついておらず、
        $(CODE @safe) 関数内のネスト関数でもない関数が、システム関数です。
	明示的に、システム関数に $(CODE @system) という属性をつけることもできます。
	システム関数はすべて安全性がない、とは限りません。
	単に、未定義動作を引き起こさないことのコンパイラによる自動保証はできない、
	ということを意味します。
        )

        $(P システム関数は、信頼済み関数やセーフ関数に対して共変$(B ではありません)
        )
)

$(V2
<h2>$(LNAME2 function-attribute-inference, 関数属性の推論)</h2>

        $(P $(GLINK2 expression, FunctionLiteral) と
        $(DDSUBLINK template, function-templates, 関数テンプレート) では、関数本体が常に見えるため、
        明示指定して上書きしない限り、
        $(LINK2 #pure-functions, $(B pure)),
        $(LINK2 #nothrow-functions, $(B nothrow)), 
        $(LINK2 #safe-functions, $(B @safe))
		属性が自動で推論されます。
        )

        $(P 属性の推論は、関数本体が書かれている場合であっても、
        そのほかの関数に対しては行われません。
        )

        $(P 推論は、
        関数本体がそれぞれの属性の規則に従っているかを検査することで行われます。
        )

        $(P 循環する関数 (つまり、
        直接あるいは間接的に自身を呼び出す関数) は、impure, throwing, @system, と推論されます。
        )

        $(P 関数内で自分自身のこれらの属性をテストしようとした場合は、
        その属性を持っていない物として推論されます。
        )
)

)

Macros:
        TITLE=関数
        WIKI=Function


        CATEGORY_SPEC=$0