(16)暗黙的型付け(その2)http://blogs.wankuma.com/rti/archive/2007/12/25/114456.aspx暗黙的型付け上記のタイトルのコメントですが、思ったよりも濃い反応をいただいたため、返信が少々長くなってしまったので、1タイトルとして独立させることにしました。前回の論点ですが「3番目のコードが有用だと思う人は、2番目のコードも許容できるのではないか?」と言う内容でした。メソッドに渡しているのだと認識するかと思います。いう変数を設けて明示したものが1・2番目のコードということになります。受け取っているのかもしれません。このコードを見ただけでは、それはわかりません。型の値を渡せていることは明白です。返す型と推論されて、その型として振舞われます。返す型と同じ型」という型名だと考えることができます。メソッドに渡せていることは明白です。変数を介さないという違いを除いて2番目のコードと同じ意味になります。以上が、ソースコードの表現として、3番目のコードに近しいのは、1番目よりも2番目であろうと考えている点についての補足です。メソッドが返す型と同じ型」という解釈は、結局ところ型を常に意識しているという点で今までと何も違いは無いように感じます。メソッド間で値を受け渡すコードを記述する際に、問題があるかどうかを調べる必要がありますが、これは上記3つのコード全てに同様です。変数を介してデータの受け渡しができることに安心感が持てる理由でもあります。現時点での結論は「使えるところは使え」です。使えないように設計されていると感じるからです。文も下記のように書いています。++i)しかし、以下のコードのように型推論できない場合は、型を明示します。this.grid.Columns)最も、ジェネリクスによるコレクションが更に主流になってくれば、上記のように書かなくてはいけないケースも少なくなって来るでしょう。その他は、こんな感じで書いています。用いる場合、用いる側(あるいは読み手)は、何に推論されるのかを知った上で書く(読む)必要があると思うのです。用いても常に型を意識しなければならないことに変わりは無い、と言うことを示しているのではないでしょうか。型についても例外ではないかと思います。};まあ、上記が前記事のコメント中で言うところの「脳内変換の慣れ」になってくるのだと思いますが、これは先のメソッドの受け渡しの「中間結果」で何となく皆さん鍛えられているんじゃないかなぁ、と言うのが僕の意見です。シャノンちなみに俺も、どちらかといえばアンチvarです。用いる場合、用いる側(あるいは読み手)は、何に推論されるのかを知った上で書く(読む)必要があると思うのです。