2017-01-05 1 views
3

형태가없는 타입의 부등식은 일단 유형 매개 변수가 그림을 입력하면 안전하지 않은 것처럼 보입니다.쉐이프리스 타입 불평등 버그?

예를 들어 다음 코드는이이 =:!= 관련이 없습니다

(우리가 String =!:= String하는 증거를 생성 한)

def someMethod[T](in : T) = { 

    implicitly[T =:!= String] 

    // some operation that requires T not String could be called here 
    // even though there is no guarantee that this is safe 
} 

val a = someMethod("abc") // here we have just proven String != String 

내 직감이 올바른 동작이 컴파일시 에러를해야한다는 것입니다 컴파일 암시 적 충돌이 부정 연산자를 에뮬레이션하는 데 사용되는 모든 상황에 적용됩니다.

이것은 정말 버그입니까, 아니면 중요한 부분을 놓치고 있습니까?

+0

셰이프가없는 문제 추적기에서 문제가 발생하여 잊어 버리지 않으시겠습니까? –

답변

1

T =:!= StringsomeMethod의 암시 적 인수 여야합니다. 우리는 T이 전화 사이트에서 String이 아니라는 증거를 수집해야합니다. 그렇지 않으면 너무 늦었습니다. 은 someMethod 본문 내에서 지워집니다.

def someMethod[T](in : T)(implicit ev: T =:!= String) = { 
    println("Definitely not a string") 
} 

scala> someMethod("abc") 
<console>:16: error: ambiguous implicit values: 
both method neqAmbig1 in package shapeless of type [A]=> shapeless.=:!=[A,A] 
and method neqAmbig2 in package shapeless of type [A]=> shapeless.=:!=[A,A] 
match expected type shapeless.=:!=[String,String] 
     someMethod("abc") 
       ^
+1

당신은 맞지만 포인트를 가지고 있습니다 ... –

+0

당신이 말하는 것을 이해하지만, 문제는 앱의 측면에 코드를 쓰는 사람들은 가능성이있는 암시를 잊어 버리는 경향이 있다는 것입니다 ... 도움을 줄 수 있습니까? 내 예제가 컴파일되는 이유를 이해할 수 있습니까? 당신은 지우개가 역할을한다고 말하지만 컴파일러가 내 예제에서 암시 적으로 생성 할 수있게하는 이유를 이해하지 못한다. 어떤 점에서'F'를 지우면 효과적으로'Any'로 바뀌는가? – luca

+0

@luca 문제는이 속임수가 암시적인 다른 암시 적 증거가 없다는 암시 적 증거를 제공함으로써 작동한다는 것입니다. 어떤 경우 무한대의 T를 증명하려고 시도 할 때 : 어떤 컴파일러도 암시 적 증거를 찾을 수 없다고 불평 할 것입니다. 그러나이 경우 T = : = String (그가 T에 대해 아무것도 모르기 때문에)이라는 증거를 찾지 못한다는 사실은 T에 대해 알려진 것이 없지만 T = :! = String이라는 문자열을 발견 할 수 있습니다. –

2

이것은 버그이거나 기껏해야 놀라운 오작동입니다.