이게 흔한 논리인데요, 실제로 명세를 많이 읽어 보고 구현도 여러 번 해 본 입장에서는 명세가 있다 없다는 것 자체가 무슨 의미가 있는진 모르겠습니다.
"명세"에는 여러 전략이 있습니다. 겉보기 동작을 중심으로 서술하는 방법과 내부 동작을 서술하는 방법이 있고, 자연어를 사용하냐 기계가 읽을 수 있는 방법(의사 코드라거나 수학적 정의)을 사용하냐가 갈립니다. 파이썬이나 러스트 언어 참조 문서 같은 것은 겉보기 동작을 자연어로 서술한 명세입니다. ISO 표준 등에서 흔히 볼 수 있는 접근은 내부 동작을 자연어로 서술한 명세인데, 이 내부 동작이 실제 구현들의 접근과 일치한다는 보장은 없으며, 대신 이 내부 동작으로 구현된 가상의 구현과 실제 구현이 서로 겉보기에 동일하게 동작observationally equivalent한다면 표준에 합치된다는 식으로 정의합니다. ECMAScript는 자연어로 서술되어 있긴 하지만 실제 구조는 사실상 의사 코드를 자연어로 쓴 수준이며, WebAssembly 같이 내부 동작을 자연어 명세와 수학 정의로 모두 제공하는 경우도 있습니다.
구현 입장에서는 자연어 명세는 거기서 다 거기입니다. 자연어 명세는 실제 구현과 별도로 만들어져야 하기 때문에 자연히 둘이 서로 동떨어지는 경우도 있을 수 있고요, 실수하는 경우도 흔히 생길 수 있습니다. 겉보기 동작이 더 구현하기 편한가 내부 동작이 더 구현하기 편한가는 상황에 따라서 다른데 프로그래밍 언어의 관점에서는 어느 한 쪽을 택해야 할 당위성이 딱히 있진 않습니다. 그런 면에서 러스트는 이미 명세가 존재하며, 다른 대체 구현이 나올 수 있을 정도로 해당 명세가 충분한 정보를 제공하는 게 맞습니다.
단순히 ISO 표준이 되었냐 안 되냐로 표준의 성숙도를 판단하고 싶으시다면, 제가 ISO/IEC 18181-1 JPEG XL 표준에서 버그를 100개 정도 발견했(고 그것 때문에 2nd amendment가 지연되고 있)다는 소식을 알려 드립니다...
rust 광팬 들의 문제점을 단편 영상으로 비꼬는 글
https://twitter.com/cmuratori/status/1367627549816152064?lang=en