Hacker News 의견들

• C++에 Contracts 기능이 표준으로 채택된 것이 아쉬움
  이미 복잡성이 한계에 도달한 언어에 또 다른 복잡성을 더하는 느낌임
  Bjarne Stroustrup도 이 기능을 “불완전하고 위원회식으로 부풀려진 설계” 라고 표현했음
  기능 자체의 위험 요소(footgun)도 많아 정당성이 부족하다고 생각함

  • 90년대 초에 C++에 Contracts 확장을 직접 구현했었음
    하지만 아무도 관심을 보이지 않았음
    관련 자료는 여기에 있음
  • 많은 사람들이 “C++은 너무 복잡하다”고 말하지만, 각자 떠올리는 복잡한 기능이 다 다르다는 점이 흥미로움
  • C++의 Contracts 설계가 잘못됐을 수도 있지만, 개념 자체는 언어 발전에 꼭 필요하다고 생각함
    Ada나 Rust처럼 정형 검증(proof assistant) 과 통합되어 테스트 대신 정적 검증을 가능하게 하는 핵심 요소임
    Ada Spark를 참고할 만함
  • Contracts에 대한 문서가 너무 혼란스러움
    cppreference 문서의 첫 예시는 오히려 상태를 변경하는 예외적인 케이스임
    문법도 직관적이지 않음
    예를 들어 asserts_pre(num >= 0) 같은 형태가 pre(num >= 0)보다 훨씬 명확했을 것임
    하지만 간결함이 우선된 듯함
  • Contracts는 이미 C++ 개발자들이 비공식적으로 해오던 일을 표준화한 것임
    복잡성을 더한다기보다는, 각자 구현하던 것을 통합해 상호운용성을 높이는 방향임
    오히려 Reflection 같은 기능이 더 복잡성을 추가한다고 봄

• C#, Java 개발자로서 궁금한 점이 있음
  C++로 요즘 어떤 종류의 애플리케이션을 만드는지 알고 싶음
  실제로 어떤 문제를 해결하는지 잘 들을 기회가 없음

• 초기화되지 않은 변수의 “erroneous behavior” 재정의가 흥미로움
  표준 문서에 따르면 런타임 비용이 생기며,
  [[indeterminate]] 속성을 사용하면 다시 undefined behavior로 돌릴 수 있음

  int x [[indeterminate]];
  std::cin >> x;
  

  • D 언어는 모든 변수를 자동으로 초기화함
    정말 초기화하지 않으려면 int x = void;처럼 명시적으로 써야 함
    실수로 그렇게 작성할 일은 거의 없음
  • 문서를 빠르게 읽어보니 두 가지가 놀라움
    1. “독립적으로 결정된 값”이란 게 정확히 무엇을 의미하는지 불분명함 — 0으로 채우는 건지, 메모리의 임의 값인지?
    2. [[indeterminate]]가 왜 다시 UB(Undefined Behavior) 로 돌아가는지 의문임
  • 아마도 이 기능은 컴파일러 플래그로 제어할 수 있을 듯함
    일부 프로젝트는 여전히 수동 초기화를 선호할 것임
  • 나중에 코드에서 [[indeterminate]]를 보게 될 사람을 생각하면 끔찍함
    결국 의미를 찾아보느라 시간을 낭비하거나, 나중엔 그냥 무시하게 될 것임
    Rust에서 제너릭과 트레잇이 너무 많아 코드 읽기 힘들었던 경험이 떠오름

• 90년대 MS의 C++ 팀에서 일했었음
  그때는 RTTI가 C++이 가질 수 있는 반사(reflection) 시스템의 한계라고 생각했음
  지금의 발전이 놀라움

• Croydon에서 회의를 열고, 서명할 때까지 아무도 못 나가게 한 건 꽤 교묘한 전략이었음
  다시는 거기서 일하고 싶지 않음

• GCC와 Clang의 C++26 구현 상황이 궁금했음
  GCC는 이미 reflection과 contracts를 trunk에 병합했지만, Clang은 어느 정도인지 알고 싶음

  • Clang 상태 페이지에는 둘 다 “no”,
    GCC 페이지에는 “yes”로 표시되어 있음
  • Bloomberg가 Clang용 reflection 구현을 여기에 공개했음
    이미 Compiler Explorer에서도 사용 가능하며, simdjson에 reflection을 추가하는 데 활용됨

• 이번 표준의 모듈 시스템 변경이 실제로 더 널리 쓰이게 만들지 의문임

  • C++ WG가 한 번쯤은 새 기능보다 모듈과 패키징에 집중해야 한다고 생각함
    Rust의 Cargo가 C++을 압도하는 이유가 바로 그 부분임
    cargo add 한 줄로 의존성을 추가할 수 없다는 점이 새 세대를 멀어지게 함
  • 대부분의 컴파일러가 아직 header unit을 지원하지 않음
    Clang의 2단계 컴파일 모델을 CMake가 채택하면 빌드 속도가 크게 개선될 것이고,
    그때야 비로소 모듈이 본격적으로 채택될 것임
  • 모듈은 이미 실패한 아이디어라고 생각함
    주류로 자리 잡을 가능성이 거의 없음
  • 솔직히 이제는 C++ 개발을 멈췄으면 함
    새로운 기능이 너무 많아 따라가기 힘듦
    빌드 시스템도 엉망이고, 헤더 파일은 이제 사라져야 함

• 주제와는 다르지만, “London Croydon”이라는 표현이 이상하게 들림
  보통 “Croydon, London”이라고 하지 않나?

  • “London Gatwick Airport”처럼 일반적인 역순 표현도 존재함
    여행 계획을 세울 때는 큰 지역부터 작은 지역 순으로 읽는 게 더 자연스러움
  • 사람마다 구체적인 것부터 말하느냐, 일반적인 것부터 말하느냐가 다름
    “London, Croydon”이라고 쓴 이유는 아마도 “런던에서 회의했다”는 인상을 주기 위해서일 것임
    “Croydon, London”은 “런던 외곽의 Croydon에서 했다”는 느낌이라 덜 멋져 보임 — 농담 섞인 해석임

• “언어 폐기 직전에 맞춰 나왔다”는 식의 냉소적인 반응도 있음

• C++29가 품질 개선과 기존 기능 다듬기에만 집중한다면 커뮤니티도 크게 불만 없을 것 같음

  • 개인적으로는 C++29에서 한 줄짜리 random() 함수만 생겨도 만족할 것임
  • 물론 어떤 기능이 추가되느냐에 따라 커뮤니티 반응은 달라질 것임