처음엔 단순하게
왜 이녀석들을 사용할때 문제가 발생할 수 있는지를 따져보다가
다시금 js런타임과 저수준 컴파일언어의 차이에대해 고민해보는 시간을 가졌음.
1. self의 반환 불가
이거는 사실 self뿐 아니라 concrete하지 않은 타입은 전부 반환값으로 등장할수 없다고 봐야 맞을거임.
타입이 그다음부터 추적이 안되기 땜에 그럼.
메소드의 실행가능여부가 아니라, 반환값타입의 추적문제일거임
2. 제네릭 파라미터 불가.
이거는 두가지의미가있음, 일단 제네릭파라미터를 막고나면 앞서말한 concrete하지 않은 반환값은 self타입밖에 안남고, self타입의 반환은 금지라서 여기서 모든 비concrete반환값을 막은 효과가있음.
문제는 왜 제네릭 자체를 인자로 가지면 안되느냐 하는거임.
여기서, 메소드 실행자체가 불가능할수도있다는거임.
사실 이렇게 두가지를 나눠놓고나면 clear했음.
self타입의 반환이 method의 실행이 불가능한거냐 아니냐,
제네릭파라미터의 사용은 method의 실행이 불가능한거냐, 그 이후에 문제가 생기느냐
이것에 대한 입장이 적힌 공식문서나 구글링이 없어서 좀 헤맸음.
여튼 일단은 내 뇌피셜로는 객체 불안정성은 두가지 문제가 있고,(1) 함수호출이후의 타입추적문제와(2)함수의 호출 자체에 문제가 생기는경우임.
위에는 (1)타입추적의 문제를 논하고있엇다면 이제부턴 2번케이스임
여튼 함수 호출 자체의 문제, 이게 제네릭타입자체를 쓸 수 없게만들음.
여기가 사실 계속해서 고민하던부분임.
자바스크립트는 모든 함수가 런타임에 동적으로 생성되는 클로저(러스트의 관점 클로저)이지만, 이새끼들은 함수는 코드영역에 박혀있는 정적인 데이터고, 함수포인터로 접근한다는게 차이임.
일반적으로 러스트에서 함수를 호출한다는것은 해당 함수포인터를 run한다고 볼 수 있고
함수들은 scope에 진입시에 동적으로 생성되는건지,
아니면 모든 가능한 declaration  들에 대해서 (설령 그곳이 if false 등으로 접근이 불가능한 스코프더라도) 컴파일타임에 일단 싹 다 코드영역에 데이터를 박아두고, 함수에 대한 접근권한을 namespace와 scope로 막아두는것인지는 몰라도
(난 보통 후자의 관점에서 상황을 이해하려고 함. 즉, 후자를 자연스럽다고 느낌)
확실한건, 권한이 있는 스코프에서 적절한 네임스페이스를 통해 함수를 접근할때에(즉, 런타임상황임), 그것은 이미 한참전부터 존재하는 데이터의 함수포인터만을 끄집어 오는 행위라는거임.
여기서 모든 함수는 동적 dispatch가 적용되지 않는다는 논리가 시작됨.
함수포인터가 변수이지만, 사실상 하드코딩된다는거임. 애초에 이거 덕분에 타입체크가 가능한거기도하고, 이부분은 레퍼런스를통해서만 들은거지만 동적인dispatch보다 최적화가 가능해짐.
이 정적 dispatch개념은, 함수포인터 변수들(이름들)과 그의 호출이 다른 런타임 변수들과는 다르게 컴파일타임에 미리 전부 배정되어있다는거고
여기에서 제네릭을 바라봐야함.
컴파일타임에 제네릭은 자신의 "문법상의 유연함"을 죄다 컴파일타임에 concrete type function들의 양산을 통해 풀어씀.
아니 그냥 애초에 function들은 타입이 죄다 concrete type임
심지어 concrete type 이더라도 unsized type이면 인자로 받아들이지도 못하는게 얘들인데,
모호한 타입을 받아들이는 함수란건 존재하지 않음.
그러면 여기서 트레잇객체의 메소드 호출을 살펴봐야함
이새끼들은 코드내에서 함수포인터를 하드코딩해둘수가없음.
함수를 하드코딩못한다는거랑 다른의미임.
내가 처음 헷갈린게 그부분이었음.
함수를 동적으로 만들어내는 클로저같은 개념이 아님.
함수 포인터를 하드코딩가능하느냐 하는 그런문제임.
그러다보니 트레잇객체의 메소드 호출은
함수포인터를 통해 이루어지는게 아님.
적절한  함수포인터를 자신의 트레잇에 맞게 "런타임에" 찾아가도록 하는 다른 타입의 데이터가 들어감.
즉, 함수포인터가 컴파일타임에 이미 하드코딩으로 바껴있는 일반적인 호출상황과 다르다는거임.
그럼 여기서 다시 돌아가서 제네릭이 왜 있으면 안되는지 살펴보자.
컴파일타임에, 해당 타입에 대한 실제 function 이 구현되어있다면,
위와같은 동적 dispatch 는 유효함.
근데 여기에 제네릭타입이 들어있는 메소드를 찾아가려고하면 문제가 생김.
애초에 런타임은 제네릭과 실제 펑션을 딱히 구분할 필요가 없을거임. 내 예상으로는 function 의 name개념도 컴파일타임에만 필요헌 개념이라, 런타임에는 제네릭펑션을 통해 컴파일된 펑션과 그렇지 않은 펑션을 기술적으로도 구분할수 없지 않을까 싶음.
문제는 해당 타입에 대한 실제 function이 구현되어있지 않을때임.
마치 vec 에서 length를 벗어나는 인덱스를 참조하려고 하면 패닉에 빠지듯이, 함수포인터를 못찾고 패닉에 빠질거임.
그리고 그래서 레퍼런스에
vtable과 제네릭은 호환이 가능하지 않다고 나오는걸거임.
하두 레퍼랑 이것저것 뒤져가면서 나름대로 뇌피셜로 짜집기해가며 이유를 찾아본거라서 틀린부분 태클걸어달라고 올리는거.

세줄요약하면, 컴파일타임에 미리 해당 타입을 준비 못해놨을수도 있음.
원래는 함수포인터들이 죄다 하드코딩되는 과정과 동시에 해당 제네릭에 대한 실행을 보장해주지만(컴파일타임), 동적 dispatch 상황에서는 해당 타입에 대한 '제네릭으로 컴파일된 펑션'이 없을 가능성이 있음.