named arguments considered harmful

珍しく言語論をぶってみるよ。

VBなんかにある名前付き引数は有害で、あんなものさっさと無くなった方が良いと思う。理由は、関数の引数名なんていう、通常は注意を払わないものが、結果的に公開APIで（も）意味を持ってしまって、単なるパラメータの変更が、公開APIの互換性を損なうことになるからだ。

たとえばこんな関数があったとしよう。

public function GetMessage (string messageID, string langage)

これを一旦安定性の求められるAPIで公開してしまったら、その後引数名を language に訂正することは出来ない。なぜなら、ユーザーが書いた以下のようなコードがエラーになってしまうからだ。

string msg = GetMessage (messageID = messageIDs.Hello, langage = "ja")

スペルミスなんて関数名でも起こりうるから、パラメータ名だけ特別視する必要ないじゃないか、と思うかもしれない。でもそんなのってバカげていると思わない?

同じ引数の組み合わせの関数をバージョンアップして、languageだけでなくregionも受け付けられるようにしたらどうなるだろう。

public function GetMessage (string messageID, string languageOrRegion)

これももはや互換性のない変更になる。パラメータ名が異なるというだけで。

つまりこれって、将来のコードに対する拡張性を無駄に制約していることになるわけだ。その自由の損なわれ方に比べて、名前付き引数が示すことができるメリットって、とっても小さいんじゃないか?

C#のアトリビュートみたいな文法なら、公開プロパティだし、問題ないのだけど。

（これは前々から思っていたことなのだけど、そんなくだらない理由でmonoのcorcompareが無駄に互換性エラーをレポートするようになったのが実に気にくわないので書いてみた。VBなんて積極的に死滅してもらいたいし、VB.NETしか開発言語として生き残っていないような未来なら、アメリカで法律屋にでもなってやる。）

追記: コメント欄も面白いのでご参考あれ。

# 派生クラスでオーバーライドされたメソッドの引数名をどう扱うかっていう問題もありそう

ちなみにVBが嫌いだからこう主張しているってわけではないですヨ。.NET言語で言えばilasmも同様の問題をかかえている(starg, ldarg)。