Выборочно отключить подчинение в Scala? (правильно введите List.contains)

Я думаю, что у меня есть законное решение по крайней мере для части проблемы, опубликованной здесь - я имею в виду проблему с List("1").contains(1): https://docs.google.com/document/d/1sC42GKY7WvztXzgWPGDqFukZ0smZFmNnQksD_lJzm20/edit

Теоретически это звучит хорошо, но, на мой взгляд, в реальной жизни все разваливается.

equals не основан на типах, а contains строится поверх них.

Вот почему такой код, как 1 == BigInt(1), работает и возвращает результат, ожидаемый большинством людей.

На мой взгляд, нет смысла делать contains строже, чем equals.

Если сделать contains более строгим, такой код, как List[BigInt](1,2,3) contains 1, полностью перестанет работать.

Я, кстати, не думаю, что «небезопасный» или «небезопасный по типу» здесь правильные термины.

Почему бы не использовать класс типов равенства?

scala> val l = List(1,2,3)
l: List[Int] = List(1, 2, 3)

scala> class EQ[A](a1:A) { def ===(a2:A) = a1 == a2 } 
defined class EQ

scala> implicit def toEQ[A](a1:A) = new EQ(a1)
toEQ: [A](a1: A)EQ[A]

scala> l exists (1===)
res7: Boolean = true

scala> l exists ("1"===)
<console>:14: error: type mismatch;
 found   : java.lang.String => Boolean
 required: Int => Boolean
              l exists ("1"===)
                           ^

scala> List("1","2")
res9: List[java.lang.String] = List(1, 2)

scala> res9 exists (1===)
<console>:14: error: type mismatch;
 found   : Int => Boolean
 required: java.lang.String => Boolean
              res9 exists (1===)

Я думаю, вы неправильно понимаете решение Мартина, это не B <: Eq, это B : Eq, что является ярлыком для

def Contains[B >: A](x: B)(implicit ev: Eq[B])

И Eq[X] тогда будет содержать метод

def areEqual(a: X, b: X): Boolean

Это не то же самое, что переместить метод equals для Any немного ниже в иерархии, что действительно не решило бы ни одной из проблем, связанных с его размещением в Any.

В расширении моей библиотеки я использую:

class TypesafeEquals[A](val a: A) {
  def =*=(x: A): Boolean = a == x
  def =!=(x: A): Boolean = a != x
}
implicit def any2TypesafeEquals[A](a: A) = new TypesafeEquals(a)


class RichSeq[A](val seq: Seq[A]) { 
  ...
  def containsSafely(a: A): Boolean = seq exists (a =*=)
  ...
}
implicit def seq2RichSeq[A](s: Seq[A]) = new RichSeq(s)

Поэтому я избегаю звонков contains.

В примерах используется L вместо List или SeqLike, потому что для применения этого решения к уже существующему contains методу этих коллекций потребовалось бы изменение кода существующей библиотеки. Одна из целей - лучший способ добиться равенства, а не лучший компромисс для взаимодействия с текущими библиотеками (хотя необходимо учитывать обратную совместимость). Кроме того, моя другая цель состоит в том, что этот ответ обычно применим для любой функции метода, которая хочет выборочно отключить функцию неявного подчинения компилятора Scala по любой причине, не обязательно привязанной к семантике равенства.

case class L[+A]( elem: A )
{
   def contains[B](x: B)(implicit ev: A <:< B) = elem == x
}

Приведенное выше приводит к возникновению ошибки при желании, предполагая, что желаемая семантика для List.contains, если входные данные должны быть равны и супертипу содержащегося элемента.

L("a").contains(5)
error: could not find implicit value for parameter ev: <:<[java.lang.String,Int]
       L("a").contains(5)
                      ^

Ошибка не генерируется, если неявное подчинение не требуется.

scala> L("a").contains(5 : Any)
defined class L

scala> L("a").contains("")
defined class L

Это отключает неявное подчинение (выборочно на сайте определения метода), требуя, чтобы тип входного параметра B был таким же, как тип аргумента, переданного в качестве входного (т. Е. Неявно включаемый в A), а затем отдельно требовать неявного доказательства того, что B является супертипом A или имеет неявно заменяемый супертип.]

ОБНОВЛЕНИЕ 3 мая 2012 г.: приведенный выше код не является полным, поскольку ниже показано, что отключение всех подчинений на сайте определения метода не дает желаемого результата.

class Super
defined class Super
class Sub extends Super
defined class Sub

L(new Sub).contains(new Super)
defined class L

L(new Super).contains(new Sub)
error: could not find implicit value for parameter ev: <:<[Super,Sub]
       L(new Super).contains(new Sub)
                            ^

Единственный способ получить желаемую форму подчинения - это также привести метод (вызов) к месту использования.

L(new Sub).contains(new Super : Sub)
error: type mismatch;
 found   : Super
 required: Sub
       L(new Sub).contains(new Super : Sub)
                           ^

L(new Super).contains(new Sub : Super)
defined class L

Согласно ответу soc, текущая семантика для List.contains состоит в том, что ввод должен быть равен, но не обязательно, супертипу содержащегося элемента. Это предполагает, что List.contains обещает, что любой совпавший элемент только равен и не обязательно должен быть (подтипом или) копией экземпляра ввода. Текущий универсальный интерфейс равенства Any.equals : Any => Boolean является единым, поэтому равенство не навязывает отношения подтипов. Если это желаемая семантика для List.contains, отношения подтипов нельзя использовать для оптимизации семантики времени компиляции, например отключение неявного подчинения, и мы застряли с потенциальной семантической неэффективностью, которая ухудшает производительность среды выполнения для List.contains.

Хотя я буду больше изучать и думать о равенстве и содержании, мой ответ остается верным для общей цели - выборочного отключения неявного подчинения на сайте определения метода.

Мой мыслительный процесс также продолжается целостно. лучшая модель равенства.

Обновление: я добавил комментарий ниже ответа soc, поэтому теперь думаю, что его точка зрения не имеет отношения к делу. Равенство всегда должно основываться на подтипных отношениях, что, как известно, предлагает Мартин Одерски о новом пересмотре равенства (см. также его версию contains). Любая специальная полиморфная эквивалентность (например, BitInt(1) == 1) может быть обработана с помощью неявных преобразований. Я объяснил в своем комментарии ниже ответ Didierd, что без моего улучшения ниже, предложенный Мартином contains afaics будет иметь семантическую ошибку, в результате чего взаимно неявно вложенный супертип (отличный от Any) выберет неправильный неявный экземпляр Eq (если он существует, иначе возникнет ненужная ошибка компилятора). Мое решение отключает неявное подчинение для этого метода, что является правильной семантикой для аргумента подтипа Eq.eq.

trait Eq[A]
{
   def eq(x: A, y: A) = x == y
}

implicit object EqInt extends Eq[Int]
implicit object EqString extends Eq[String]

case class L[+A]( elem: A )
{
   def contains[B](x: B)(implicit ev: A <:< B, eq: Eq[B]) = eq.eq(x, elem)
}
L("a").contains("")

Примечание. Eq.eq можно при желании заменить на implicit object (не отменять, потому что нет виртуального наследования, см. Ниже).

Обратите внимание, что по желанию L("a").contains(5 : Any) больше не компилируется, потому что Any.equals больше не используется.

Мы можем сокращать.

case class L[+A]( elem: A )
{
   def contains[B : Eq](x: B)(implicit ev: A <:< B) = eq.eq(x, elem)
}

Добавить: x == y должен быть вызовом виртуального наследования, т. е. x.== должен быть объявлен override, потому что нет виртуального наследование в Eq классе типов. Параметр типа A является инвариантным (поскольку A используется в контравариантной позиции как входной параметр Eq.eg). Затем мы можем определить implicit object на интерфейсе (он же trait).

Таким образом, переопределение Any.equals должно по-прежнему проверять соответствие конкретного типа ввода. Компилятор не может удалить эти накладные расходы.