正確にタイプ消去が発生すると、

Question

scalaの構文は非常に有望です。私はもともとscalaは単なる快適なJava以上のものであり、まったく新しいプログラミングパラダイムを導入することができると考えましたが、構文によって許される多くの機能は意味論では間違っています。だから私はスカラの限界とハックを見つけてそれらを排除するための探求を始めました。私はちょうど他の視点からのスカラ方法とパターンに対応するためのテストプロジェクトを書いていますが。

主な障害は、jvm実装から継承された型消去です。私は小さな消しゴムが壊れてしまった10の美しい模様を書くことができます。それは、タイプ消去がジェネリックを汚染すると言われていますが、私はミックスインでタイプ消去を偶然見つけました。私はそれがscalinのmixinの実現に問題であると考えます。ミックスインとミックスイン

trait B2 extends B1 { 
    def typeMe(x:T1 with T2) {} 
} 

ワーキングコードと

プリアンブル

trait T1 
trait T2 

trait B1 { 
    def typeMe(x:T1){} 
} 

壊れたコードは、別々の形質として宣言

trait T3 extends T1 with T2 
trait B3 extends B1 { 
    def typeMe(x:T3) {} 
} 

エラーがある：

error: name clash between defined and inherited member: 
method typeMe:(x: T1 with T2)Unit and 
method typeMe:(x: T1)Unit in trait B1 
have same type after erasure: (x: $line12.$read#$iw#$iw#T1)Unit 
    def typeMe(x:T1 with T2) 

ベストプラクティスは何ですか？新しい特性を導入すると、（特に大きなミックスインチェーンの場合）冗長性があり、型の非互換性が生じます。疑似暗黙の引数を追加することは、オーバーヘッドを増加させるので、同様に銀色の弾丸ではありません。

---

更新：

私は非常に申し訳ありませんが、私は間違った質問をしてきました。私は説明されたエラーの性質上、その回避策ではなく、より多くのことに興味を持っています。型消去はどこで行われますか？タイプ消去ソースとみなされるコードにはジェネリックスがありません。コンパイラの動作の背後にある機構は何ですか？

Answer 1

あなたがしようとしていることにはいくつか問題があります。

まず、タイプ消去が発生したときは問題ありません。これは、タイプ消去の概念は、計算の前または後にタイプを消去するかどうかにかかわらず、結果は同じでなければならないからです。 JVM言語では、コンパイル時に何らかの消去が発生します（iinm）。

第2に、あなたの「働く」コードは、あなたが思うように実際には機能しません。これには、サブタイプ、共分散、反変異についての理解が必要です。 （Foo <: Barは「FooはBarのサブタイプです」、または「FooはBarよりも具体的です」という非公式に意味します）。関数は入力に反変であり、出力には共変であり、W <: AとB <: Vの場合にのみ関数A => B <: W => Vが使用されます。

今、あなたの関数を考えてみます。B1.typeMeへの入力タイプがT1ている間B3.typeMeへ

B1.typeMe(x:T1) 
B3.typeMe(x:T3) 

入力は、T3です。しかし、T3 <: T1従ってB3.typeMeできないのタイプはB1.typeMeの型のサブタイプである、（T3はT1よりより具体的です）。代わりに、単に別々の機能と見なされ、不気味なシャドウイングが時々起こります。正直なところ、これはおそらくエラーまたは少なくとも警告を出すはずです。ありがたいことに、他のバージョンがあります。