回答編集履歴

2

改善

2019/10/20 14:07

投稿

nobonobo
nobonobo

スコア3367

test CHANGED
@@ -48,7 +48,7 @@
48
48
 
49
49
 
50
50
 
51
- これではインターフェースとの互換性チェックがむやみに複雑になるし、
51
+ これではインターフェース非インターフェース型の互換性チェックがむやみに複雑になるし、
52
52
 
53
53
  あとから定義を見直したときにも互換が取れているのかが読み取りにくくなります。
54
54
 

1

追記

2019/10/20 14:07

投稿

nobonobo
nobonobo

スコア3367

test CHANGED
@@ -13,3 +13,45 @@
13
13
  以上の全てが一致して初めてそのメソッドをサポートしてる扱いになるといのが原則です。
14
14
 
15
15
  受け渡しされるものが同じ型かどうかは関係ありません。
16
+
17
+
18
+
19
+ ----追記----
20
+
21
+
22
+
23
+ 挙動自体は把握されてるとのことなので
24
+
25
+ あとからこの質問を参照する人のために補足だけ追記しておきます。
26
+
27
+
28
+
29
+ あくまで「InterfaceA」と「*StructA」は異なる値をもつ型です。
30
+
31
+ (前者は値と型を値として格納されており、後者は値のみです)
32
+
33
+ ある構造体をあるインターフェースの値に代入する時、互換がある場合は
34
+
35
+ 暗黙(自動)で型変換されるという機能があるだけです。
36
+
37
+
38
+
39
+ 仮に例示のメソッドの返値の型が「InterfaceA」と「*StructA」のどちらを記述しても
40
+
41
+ インターフェースとしての互換性があると判定できるようになっていたとしても思い当たるようなメリットがありません。
42
+
43
+
44
+
45
+ その判定を行うためには「あくまで異なる型」を一度互換がとれていると仮定して
46
+
47
+ 互換が取れているのかを確認する必要が出てきます。
48
+
49
+
50
+
51
+ これではインターフェースと値の互換性チェックがむやみに複雑になるし、
52
+
53
+ あとから定義を見直したときにも互換が取れているのかが読み取りにくくなります。
54
+
55
+
56
+
57
+ なのでインターフェースの互換チェックではメソッドのシグネチャ(メソッド名や入出力パラメータの数や型)が合致するかどうかというシンプルなルールだけで判定されます。