mixin？？？

D

これじゃ、単なるdefineだと思ったのは私だけじゃありますまい。

さいしょちょっと面白そうに思ったのですが、スコープが宣言場所じゃなくて使用場所、つまりdynamic scope寄りになってるし、インライン展開が見込めるところからして単なる型付きdefine。

それはそれで、あると便利なのかもしれませんが、Rubyのmodule-mixin, Delphiのクラス/interface委譲、Uvaのメソッド委譲なんかを思うと…あああ。

使い方によっては、interfaceを実装するようなtemplateを書くことで、本物のというか期待してたmixinの代わりになるのかも知れませんが…が…そんなの、ATLやVCL@C++Builderがウィンドウメッセージをマクロで振り分けてるのと一緒だー！

泣いてやります。
私的にはGNATがクロージャをサポートした時点でDは追いかける価値を無くすかも…ってこれも散々今までわめいた気がするのですが、今度のは決定的。
ひょっとしたらdefineのinline関数では埋め切れない点を埋めたかったのかもしれませんが、それならそれでmixinなんて名前を…。

それにしても、k.inabaさん、コンパイラの新バージョンが出たわけでもないのに、仕事早いですね…

C++では？

C++

C++マスターの皆様には常識なのかも知れませんが、私は知らないので試してみました。

#include
using namespace std;

string const m = "global";

template 
void A(T arg)
{
	cout << m << arg << endl;
}

int main()
{
	string const m = "local";
	A(100);
}

...>bcc32 temp
Borland C++ 5.6.4 for Win32 Copyright (c) 1993, 2002 Borland
temp.cpp:
Turbo Incremental Link 5.65 Copyright (c) 1997-2002 Borland

...>temp
global100

ふむ、static scope。常識的動作。こうじゃないとバグの温床ですよね。
一応dmcでも試して見ましたが同じでした。

そしてD

D

Dに不都合を避けるための変な命名規則が追加されない事を祈ります。
本気で避けようとするならば、グローバル識別子をtemplate中で使うのを避けて全部引数で貰うとか、常にモジュール名からだらだら書くか…
いやまてよ。templateが宣言されたモジュールがprivate importしているモジュールで宣言された識別子を使っていた場合、それを更にimportしたモジュールからそのtemplateをmixinするとわけわからんエラーに見舞われるのでは？

見渡す限り、結構好意的に受け取られてるのが、信じられんです。

…Dでも、templateを普通に使うと、宣言場所のスコープで解決されますので、不統一です。…ということで、バージョンがふたつかみっつ進んだあたりで直されそう、と予言しておきましょう。

スコープの話題はさておいて。
仮想関数とかも追加できるということは、BEGIN_MESSAGEマクロと同じように展開されるようなものは書けるのでしょうか？

//嘘コード
class My_Window : Window 
{
  ...

  //実は仮想関数dispachをoverrideしてswitch〜caseを追加している
  mixin message_dispacher!(My_Window, Window,
    message_handler!(WM_SIZE, wm_size_handler),
    ...
  );

  void wm_size_handler(WPARAM w, LPARAM l)
  {
    ...
    //親クラスにWM_SIZEのハンドラがあればそれを、無ければデフォルトハンドラ(DefWindowProcなど)を探す
    mixin inherited!(WM_SIZE) super_handler;
    super_handler.call(w, l);
  }

  ...
}

できたらそれはそれで便利な気がします。
まんまマクロの用法ですが。