고신뢰성 C++ 코드를 작성하지만 표준화 과정에는 전혀 관여하지 않는 입장에서, C++ Contracts가 실제 코드베이스의 어떤 문제를 해결하는지 불분명함. 특히 C++20 Concepts가 나온 뒤에는 더 그러함.
이미 신뢰성을 높이는 기법을 쓰고 있다면 이득을 정량화하기 어렵고, 그렇지 않더라도 기존 관용구를 조금 더 수고해 적용하는 것에 비해 절약되는 것이 거의 없음. 제한된 경우의 표현을 표준화하지만 보상은 미미해 보임.
제공하는 기능 대부분은 constexpr와 C++20 Concepts로 이미 가능한 것을 섞어 놓은 듯함. 컴파일러도 그 조합을 대부분 분석할 수 있고 표현력도 충분하므로, 설득력 있는 표준 기능이라면 기본적으로 훨씬 강한 보장을 제공해야 함. 지금의 Contracts는 현행 표준 기능들이 나오기 훨씬 전에 설계된 기능처럼 보임.
이 글을 보고서야 contracts와 concepts가 서로 다르다는 걸 깨달았음. Concepts는 기본적으로 제약이 있는 제네릭 아닌가?
Concepts는 타입의 타입이고, Contracts는 구조화된 런타임 단언문임. 둘은 전혀 다른데 무슨 관계가 있다는 것인가?
글을 보면 보통 찬성·반대·기권이 있는데, 이번에는 네 번째 선택지인 불승인(disapproval) 이 나온 것처럼 읽힘. 실제로 그런 것인가, 아니면 그냥 부결됐다는 뜻인가?
승인에 필요한 3분의 2 찬성을 얻지 못해 부결된 것임.
C++ contracts를 둘러싼 논란은 이해하지만, 정적 분석기·모델 검사기·자동 정리 증명기 같은 외부 도구가 검증할 수 있는 분석 시점의 계약 주석은 대단히 유용함.
C에서 CBMC와 사용자 정의 매크로로 함수 계약과 불변식 체계를 만들어, 조합적 검증을 통한 정형 기법을 적용하고 있음. C를 택한 이유는 언어가 비교적 단순하고 도구를 만들기도 쉬워서임. C++ contracts가 일부 대응 기능을 제공하면 C 대신 C++의 장점을 활용할 수 있게 됨.
현재 형태는 부적합하지만, 제안을 다듬고 구현을 단순화해 미래 버전에 다시 제안하길 바람. Contracts는 C++와 Ada / SPARK 같은 언어 사이의 안전성 격차를 줄여줄 수 있음.
Contracts는 유용하지만 타입 안전성과 메모리 안전성을 우회할 수 있다면 아무것도 보장하지 못함.
ISO 위원회는 올바른 결정을 내렸다고 봄. 현실에서는 이미 메모리 안전성과 실행 무결성을 핵심 과제로 여기고 C++를 더 이상 적합한 선택으로 보지 않으며, 그 판단이 맞다고 생각함. 작업 그룹의 우선순위가 잘못돼 있음.
개인적으로 C++는 새 기능 추가를 좀 자제하고, char8_t와 std::filesystem의 엉망인 상태부터 정리했으면 함.
std::regex도 좀 빨라졌으면 함. 별다른 이점도 없이 끔찍하게 느리다고 함.
Contracts를 언어에 넣고 싶어 하는 이유는 이해하지만, C++는 계속 덧붙는 복잡성에 짓눌리고 있음. C++26의 오류 동작(erroneous behavior) 처럼 언어의 결함을 줄이는 제안이 더 나왔으면 함.
Contracts가 템플릿 메타프로그래밍보다 읽기 쉽고 오류 메시지도 좋아서 사용상의 복잡성을 줄인다는 논리는 가능함. 하지만 다른 기능에 대한 WG21의 실적을 보면 설득력이 무너짐. 코루틴은 동시성 코드를 쉽게 작성하는 수단으로 소개됐지만, 개인적으로는 완전히 실패해 가망 없을 만큼 복잡하고 혼란스러워졌다고 봄. 모듈도 겉으로는 단순해 보이지만 실제 도입 과정의 세부 사항이 너무 복잡해 아무도 손대려 하지 않는 형편임.
여러 국가 표준 기관이 Contracts를 아직 출시할 준비가 안 된 기능으로 본 것은 현명한 판단임. C++에는 수십 년간 정의가 불명확한 기능이 너무 많았고, 또 하나 늘어나는 것을 피하려 한 셈임.
나는 C++11 기능 집합에 머물러 있어 직접적인 이해관계는 없음.
반대표 때문에 신뢰와 존중에 기반한 협업 체계가 흔들렸다는 대목은 이해하기 어려움. ISO가 의도적으로 2단계 승인 절차를 요구한다면, 두 번째 단계의 투표권을 행사하는 게 왜 신뢰를 저버리는 행위인가?
글쓴이가 원하는 방향으로 투표하지 않았기 때문이라고 봄. 호의적인 해석은 아니지만, 5분 동안 다른 설명을 찾거나 떠올려 보려 해도 찾지 못했음.
C++를 써 본 적은 있지만 손을 놓은 지 오래라 어느 편도 아님. 지금 표준에 넣는 것이 적절한지에 관해 실질적인 견해차가 충분히 존재하며, 절차가 설계대로 작동한 것으로 보임.
C++를 자세히 따라가지는 않으니 틀렸다면 정정해 주길 바람. 이전 HN 토론을 보면 블로그가 에둘러 가리킨 반대 문서는 Bjarne Stroustrup의 문서로 추정됨. 내 기억으로는 그가 C++26 표준화의 최종 형식적 투표를 부결시키기 위해 물밑에서 움직이겠다고 이미 밝힌 것으로 알고 있음.
맞음. 관련 Reddit 토론들을 따라가 보니, 자기 견해에 반대할 사람들이 잠들어 있을 법한 시간에 아주 짧은 사전 공지만 하고 기습 투표를 잡는 등 부적절한 전술을 썼다고 함.
Bjarne Stroustrup에 대한 비방전이 벌어지는 듯하지만, 실제 사정은 훨씬 단순하고 음모와도 거리가 멀다고 봄.
현행 Contracts 제안에 결함이 있고 C++의 핵심 원칙에도 어긋난다는 문서가 적어도 2017년부터 나와 있음. Contracts도 그 문제들도 새로운 것이 아니며, 표준에서 반복해서 빠졌는데도 제안은 아직 수정되지 않았음.
통과하지 못할 것이 분명한, 결함이 널리 알려진 기능을 왜 굳이 밀어 넣었는지 물어야 함. 외부에서 보기에는 지지자들이 수년째 지지를 얻지 못한 기능을 관료적 수법과 이례적인 절차를 쓰겠다는 위협으로 강행하려다가 실패하고 반대 세력을 탓하는 모습임.
2025년의 “contracts concerns”, 2026년의 “contracts fundamental flaws” 같은 문서까지 있는데, 합의 기반의 표준화라고 볼 수 있겠는가? 우려와 경고를 무시하고 절차를 밀어붙이다가 허세와 위협이 통하지 않자 반발하는 것으로 보임.
C++는 SIMD를 거대한 내장 함수 모음으로 두기보다 고수준 언어 기능으로 만드는 데 집중해야 함. AVX 코드는 읽을 수가 없음.
SIMD는 컴파일러 수준에서 해결할 수 없음. 하드웨어별 SIMD 기능 차이가 근본적으로 커서, 사용 맥락과 플랫폼에 맞는 자료구조와 알고리즘이 필요함.
서로 다른 하드웨어의 SIMD는 컴파일러의 코드 생성 조작으로 다룰 수 있는 수준보다 훨씬 높은 추상화 계층부터 호환되지 않음.
SIMD/AVX를 통합하려는 프레임워크는 있지만 추상화에는 비용이 따름. 지금 필요한 것은 더 나은 추상화가 아니라 더 나은 하드웨어와 저수준 인터페이스임.