Bản thảo C++26 trượt bỏ phiếu DIS: Hợp đồng (contracts) trở thành tâm điểm tranh cãi

Bản thảo tiêu chuẩn C++26 đã thất bại trong vòng bỏ phiếu DIS (Draft International Standard) của ISO. Theo những gì được ghi nhận, đây là lần đầu tiên một bản nháp C++ bị từ chối ở giai đoạn này. Robert Seacord, chủ tịch ủy ban C, cho biết ông không nghĩ rằng bất kỳ tiêu chuẩn ngôn ngữ nào thuộc SC22 từng trượt bỏ phiếu trước đây. Daveed Vandevoorde, thành viên Nhóm Định hướng của WG21 (P5000R1), cũng xác nhận rằng chưa từng có bản nháp C++ nào nhận dù chỉ một phiếu chống.

Hệ quả là các tính năng quan trọng như reflection, std::execution, library hardening và contracts đều nằm trong một bản nháp mà ISO chưa phê duyệt. Hiện vẫn chưa ai biết chính xác độ trễ sẽ kéo dài bao lâu.

Kết quả bỏ phiếu: trượt cả hai điều kiện

Cuộc bỏ phiếu khép lại vào ngày 23/10/2026. Bản nháp đã không đáp ứng được cả hai điều kiện bắt buộc của một DIS:

• Số phiếu thuận từ các thành viên có quyền bỏ phiếu (P-members): cần ít nhất 2/3, nhưng chỉ đạt 12/20, tức 60%.
• Số phiếu chống từ tất cả cơ quan tham gia bỏ phiếu: không được vượt quá 25%, nhưng thực tế là 9/22, tức 41%.
• 2/3 của 20 cần 14 phiếu thuận, trong khi bản nháp chỉ có 12.
• 1/4 của 22 cho phép tối đa 5 phiếu chống, nhưng bản nháp nhận tới 9.

Chỉ riêng một trong hai điều kiện này bị vi phạm cũng đủ khiến bản nháp thất bại.

Quốc gia nào bỏ phiếu chống?

Kết quả chính thức nêu rõ từng quốc gia. Chín nước bỏ phiếu Không: Đan Mạch, Phần Lan, Iran, Ý, Nhật Bản, Luxembourg, Romania, Tây Ban Nha và Thụy Điển. Mỗi nước đều gửi kèm nhận xét với lá phiếu của mình. Pháp và Ireland bỏ phiếu trắng nhưng cũng gửi nhận xét, nâng tổng số quốc gia có ý kiến lên 11. Ba Lan và Hoa Kỳ bỏ phiếu trắng.

Nội dung các nhận xét hiện chưa được công bố. Theo Chỉ thị ISO/IEC (khoản 2.6.5 Phần 1), phải có báo cáo đầy đủ trong vòng 12 tuần kể từ khi kết thúc bỏ phiếu, bao gồm kết quả, quyết định của chủ tịch ủy ban và toàn văn các nhận xét. Với cuộc bỏ phiếu kết thúc ngày 23/10, thời hạn muộn nhất là giữa tháng 1/2027.

Contracts: tâm điểm của mọi tranh cãi

Tác giả bài viết gốc tin rằng cả chín phiếu chống đều liên quan đến contracts. Đây là nơi phe phản đối đã công khai lập trường trước khi bỏ phiếu, và cả hai phản đối được trình bày tại phiên họp toàn thể ở Croydon đều xoay quanh tính năng này.

Đoạn mã minh họa contracts trông như sau:

double checked_sqrt(double x)
pre (x >= 0.0)
post (r : r >= 0.0)
{
    const double root = std::sqrt(x);
    contract_assert(!std::isnan(root));
    return root;
}

Điểm mấu chốt gây tranh cãi: đoạn mã này không quyết định liệu từng kiểm tra có được chạy hay không, cũng không nói điều gì xảy ra khi một kiểm tra thất bại. Bản nháp định nghĩa bốn ngữ nghĩa đánh giá — ignore, observe, enforce và quick-enforce — và để việc lựa chọn giữa chúng cho từng bản triển khai. Trong GCC 16, người dùng chọn bằng một cờ biên dịch.

Phần lớn tranh chấp xoay quanh lựa chọn này: liệu một contract assertion là kiểm tra mà bản build có thể lược bỏ, hay là một bảo đảm mà chương trình có thể dựa vào?

Lập luận ủng hộ contracts

Tác giả bài viết gốc thừa nhận ông yêu thích contracts như một ý tưởng và đã tiếc nuối từ khi chúng bị loại khỏi C++20. Với ông, contracts mang lại hai lợi ích song hành:

• Kiểm tra: chương trình có thể tự xác minh các giả định của chính nó.
• Tài liệu: điều kiện tiên quyết (precondition) và hậu điều kiện (postcondition) trong chữ ký hàm ghi lại ý định của người thiết kế API, giúp người dùng biết cần kỳ vọng gì. Các hệ thống tài liệu như Doxygen hay cppreference.com có thể hiển thị chúng ngay tại chỗ.

Một bình luận cũng có thể nói điều tương tự, nhưng không có gì giữ nó luôn đúng. Bình luận có thể trôi dạt khỏi mã mà không ai nhận ra, trong khi contract là một phần của mã — trình biên dịch kiểm tra nó cùng với hàm, và khi bật chế độ kiểm tra, vi phạm sẽ báo lỗi rõ ràng nên tài liệu này không thể lặng lẽ lỗi thời. Concepts đã làm được điều này cho kiểu dữ liệu mà hàm chấp nhận, ở thời điểm biên dịch. Contracts là mảnh còn thiếu, thực hiện điều tương tự cho các giá trị ở thời điểm chạy.

Điều gì sẽ xảy ra tiếp theo?

Theo chỉ thị ISO/IEC, sau khi một DIS thất bại có bốn hướng hành động:

1. Phát hành lại bản nháp điều tra đã sửa đổi, với thời gian bỏ phiếu 8 tuần thay vì 12.
2. Phát hành lại bản nháp ủy ban đã sửa đổi để lấy ý kiến.
3. Phát hành dưới dạng đặc tả kỹ thuật nháp (Draft Technical Specification).
4. Hủy dự án.

Chủ tịch SC22 sẽ chọn một trong ba phương án đầu tiên, phối hợp với ban thư ký SC22, chủ tọa WG21 và tham vấn văn phòng trung tâm ISO/IEC. Việc hủy dự án là phương án duy nhất mà toàn bộ SC22 phải quyết định.

Cuộc họp WG21 tiếp theo diễn ra tại Búzios, Brazil từ ngày 16 đến 21/11/2026 — đây sẽ là cuộc họp toàn ủy ban đầu tiên sau khi có kết quả, và quan điểm về hướng đi đang chia rẽ:

• Một số người muốn WG21 xin bỏ phiếu lại mà không thay đổi hay loại bỏ contracts. Đề xuất P4433R0 chính thức hóa yêu cầu này.
• J. Daniel Garcia, một trong các tác giả của P4238R1, viết: "Giải pháp ngắn hạn rất đơn giản: loại bỏ một tính năng có vấn đề và phần còn lại của tiêu chuẩn rất có thể sẽ được phê duyệt".
• Vandevoorde khuyến nghị nên loại contracts khỏi bản nháp, với điều chỉnh để giữ lại library hardening.
• Một số nhận xét trước đó của các cơ quan quốc gia đề xuất dùng đặc tả kỹ thuật hoặc sách trắng thay thế.

Ý nghĩa với mã nguồn hiện nay

Trình biên dịch vẫn triển khai các tính năng từ bản nháp đang làm việc, và việc bỏ phiếu không thay đổi những gì chúng đã phát hành. GCC 16 chấp nhận cờ -std=c++26, còn Clang có -std=c++2c. GCC 16 triển khai contracts như một phần hỗ trợ C++26 thử nghiệm, trong khi bản triển khai của Clang chưa được hợp nhất.

Nếu nhóm của bạn đã dùng hoặc đang học các tính năng C++26 thì chưa cần hoàn tác gì. Tuy nhiên, cần lưu ý rằng những gì trình biên dịch triển khai hiện nay vẫn là bản nháp và có thể không khớp với tiêu chuẩn được phát hành. Cho đến khi một ấn bản mới được công bố, tiêu chuẩn C++ hiện hành vẫn là ISO/IEC 14882:2024 (C++23).

Những câu hỏi còn bỏ ngỏ

• Toàn văn nhận xét của 11 quốc gia đã gửi — chưa công bố.
• WG21 sẽ khuyến nghị gì tại Búzios, phương án hành động nào được chọn và theo lịch trình nào.

Với cộng đồng lập trình viên Việt Nam đang theo dõi lộ trình C++26, đây là lời nhắc rằng các tính năng mới vẫn có thể thay đổi trước khi tiêu chuẩn chính thức được chốt. Việc thử nghiệm trên các cờ trình biên dịch là hữu ích, nhưng không nên xem đó là cam kết dài hạn cho mã nguồn sản phẩm.