
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s tech blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, distributed training, and data engineering.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Thu, 16 Jul 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/wg21/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/2026-07-16-cpp26-contracts-shipped-anyway</guid>
    <title>C++26 계약(Contracts) — 114 대 12로 통과된 기능, 그리고 GCC 16.1이라는 유일한 구현</title>
    <link>https://www.youngju.dev/blog/2026-07-16-cpp26-contracts-shipped-anyway</link>
    <description>2026년 3월 28일 WG21은 C++26의 기술 작업을 끝냈습니다. 표결은 만장일치가 아니었고(찬성 114, 반대 12, 기권 3), 비만장일치의 주된 이유는 계약(contracts)이었습니다. 계약은 pre·post·contract_assert로 사전조건과 사후조건을 언어 차원에서 적는 기능이지만, 그 검사가 실제로 실행될지는 소스 코드가 아니라 빌드 설정이 정합니다 — 표준 문구 그대로 &quot;구현 정의(implementation-defined)&quot;입니다. 반대측은 헤더의 inline 함수 하나로 이 설계가 왜 안전을 해치는지를 보였고(P3835R0), 찬성측은 기능적 안전과 언어 안전은 다른 목표이며 최악이라 해봐야 검사가 건너뛰어질 뿐 새 버그가 생기지는 않는다고 반박했습니다(P3846R0). 이 글은 양측의 실제 논증, 표준 초안의 정확한 문구, 코나에서 실제로 고쳐진 것과 끝내 못 들어간 &quot;반드시 검사&quot; 문법(P3911), 그리고 2026년 7월 현재 이 기능을 구현한 컴파일러가 GCC 16.1 하나뿐이라는 이식성 현실을 정리합니다. 결론부터 말하면, 계약은 신뢰 경계 검증에 쓰라고 만든 물건이 아닙니다.</description>
    <pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>cpp</category><category>cpp26</category><category>contracts</category><category>wg21</category><category>gcc</category>
  </item>

    </channel>
  </rss>
