Fitur C++ yang Dilarang di Chromium

 (chromium.googlesource.com)
15 poin oleh GN⁺ 2026-01-26 | 3 komentar | Bagikan ke WhatsApp
  • Proyek Chromium mendefinisikan dengan jelas cakupan penggunaan dan daftar larangan fitur standar C++ modern untuk menjaga konsistensi kode dan keamanan
  • Dari C++11 hingga C++23, tiap standar dibagi ke dalam status diizinkan, dilarang, atau ditinjau (TBD), dan library Abseil juga mengikuti kriteria yang sama
  • Fitur yang dilarang mencakup std::shared_ptr, std::function, std::regex, std::filesystem, std::byte, char8_t, modules dan lainnya
  • Fitur yang diizinkan mencakup concepts, operator spaceship, designated initializer, std::to_underlying, algoritme std::ranges dan lainnya
  • Panduan ini berlaku untuk Chromium dan seluruh subproyeknya, serta berfungsi sebagai standar inti untuk menjamin stabilitas kode dan kompatibilitas build

Kebijakan penggunaan Modern C++ di Chromium

  • Chromium tidak langsung mengadopsi standar C++ terbaru, melainkan menandainya sebagai status dukungan awal (initially supported) hanya setelah dukungan toolchain cukup matang
    • Setelah itu, tiap fitur diklasifikasikan sebagai diizinkan (allowed), dilarang (banned), atau sedang ditinjau (TBD)
  • Perubahan status fitur baru dapat diusulkan melalui mailing list cxx@chromium.org
  • Setelah dua tahun sejak dukungan awal, fitur dipindahkan ke daftar diizinkan atau dilarang melalui peninjauan eksplisit

Fitur C++11 yang dilarang

  • Fitur bahasa: inline namespace, long long, user-defined literals
  • Fitur library: <chrono>, <regex>, <random> engine, <exception>, <ratio>, <thread> dan lainnya
    • Exception dinonaktifkan sepenuhnya, dan hanya noexcept yang diizinkan
    • Sebagai pengganti std::bind, std::function, std::shared_ptr, std::weak_ptr, digunakan base::Bind, base::Callback, base::RefCounted

Fitur C++17 yang dilarang

  • Literal karakter UTF-8 (u8) dilarang karena masalah kompatibilitas dengan char8_t
  • Item library yang dilarang:
    • fungsi matematika khusus, algoritme paralel, std::any, std::byte, std::filesystem, resource memori std::pmr dan lainnya
    • Algoritme paralel dilarang karena libc++ belum mendukungnya dan ada kekhawatiran benturan dengan model threading Chrome

Fitur C++20 yang diizinkan dan dilarang

  • Fitur bahasa yang diizinkan:
    • concepts, consteval, designated initializers, operator spaceship, [[likely]], sintaks inisialisasi range-for
  • Fitur library yang diizinkan:
    • <bit>, <compare>, <concepts>, <numbers>, std::erase_if, std::ranges::subrange, std::to_underlying dan lainnya
  • Fitur yang dilarang:
    • char8_t, modules, [[no_unique_address]], std::bit_cast, <span>, std::bind_front, std::ranges::view_interface
  • Sedang ditinjau (TBD): coroutine, <format>, <source_location>, std::u8string

Fitur C++23 yang diizinkan dan sedang ditinjau

  • Fitur bahasa yang diizinkan: #elifdef, if consteval, static operator
  • Fitur library yang diizinkan: std::byteswap, std::basic_string::contains, std::to_underlying, algoritme perluasan std::ranges
  • Fitur yang sedang ditinjau: std::expected, std::mdspan, std::generator, std::stacktrace, std::print, [[assume]], #warning dan lainnya

Kebijakan library Abseil

  • Komponen Abseil yang dilarang:
    • absl::any, absl::optional, absl::StatusOr, absl::Span, absl::FunctionRef, absl::Mutex, absl::Time, absl::btree_* dan lainnya
    • Sebagian besar digantikan oleh implementasi namespace base milik Chromium (base::span, base::expected, base::Bind, dll.)
  • Sedang ditinjau (TBD): absl::linked_hash_set, absl::linked_hash_map

Makna secara keseluruhan

  • Chromium tidak menerima fitur standar C++ begitu saja, melainkan menerapkannya secara selektif berdasarkan stabilitas build, keamanan, performa, dan konsistensi kode
  • Sebagian besar fitur yang dilarang berasal dari implementasi yang tumpang tindih (base::) atau masalah kompatibilitas toolchain dan ABI
  • Panduan ini berfungsi sebagai dokumen standar pengelolaan kualitas kode C++ di ekosistem Chromium, dan menjadi referensi penting dalam kolaborasi open source

Bacaan terkait

3 komentar

 
karikera 2026-01-27

Saya agak menyayangkan bahwa C++ terus membengkak demi menjaga kompatibilitas ke belakang..
 
tsboard 2026-01-26

Ini benar-benar bahasa yang sangat besar seperti yang dikatakan dalam pendapat HN tentang C++ ...
 
GN⁺ 2026-01-26
Komentar Hacker News

  • Tidak ada yang terlalu menonjol, tetapi sebagian besar isinya pada dasarnya adalah “untuk kebutuhan kami, mari pakai library buatan internal”
    Sisanya juga cukup masuk akal, seperti menghindari masalah locale. Ada juga opsi untuk merapikan sisi kasar dari standard library, jadi bisa dipahami

    • Saya sering melihat kasus seperti ini di perusahaan dengan codebase lama. Dulu belum ada chrono, jadi mereka membuat tipe waktu sendiri, dan sudah memakai container buatan sendiri sejak sebelum STL stabil
      Kalau memulai proyek baru sekarang, sepertinya sebagian besar aturan ini tidak akan terlalu berarti
    • Alasan char8_t dilarang cukup menarik. Encoding selain UTF-8 sekarang hampir tidak ada, dan char8_t* tidak kompatibel dengan char*, jadi mereka menganjurkan penggunaan std::string atau std::string_view untuk mencegah banjir casting
    • Sebagai orang yang mengelola halaman ini selama lebih dari 10 tahun, saya heran dokumen ini muncul di r/c++ dan HN pada hari yang sama. Tidak ada hal yang benar-benar baru, jadi saya penasaran kenapa tiba-tiba ramai dibahas
    • Beberapa bagian bukan sekadar karena inersia, tetapi karena implementasi Google memang punya desain yang secara ketat lebih baik daripada standar. Tipe standar sebenarnya bisa saja dirancang lebih baik
    • Ada anggapan bahwa di internal Google ada versi buatan sendiri untuk hampir semua teknologi. Masalahnya, sebagian orang meniru itu secara membabi buta hingga kehilangan konteks. Contoh paling jelas adalah organisasi dengan 20 developer dan 50 layanan yang tetap mengadopsi Kubernetes

  • Membaca soal code lama membuat saya teringat saat Chromium pertama kali muncul
    Fakta bahwa codebase ini dimulai sudah 20 tahun lalu terasa mengejutkan lagi

  • Melarang <regex> adalah keputusan yang tepat. Dulu ini tidak bisa dipakai karena tidak menangani UTF-8 dengan benar. Aneh juga desain yang cacat seperti ini bisa distandardisasi

    • Sekarang sebagian besar library regex mendukung mode Unicode. Regex sendiri adalah teknologi yang lahir lebih dulu daripada UTF-8

  • Ada dokumen yang lebih menarik di direktori atas
    Panduan gaya C++ Chromium layak dibaca

  • Exception memang dilarang, tetapi Windows menjadi pengecualian

    • Kode Google pada dasarnya berakar pada gaya C, jadi tidak exception-safe. Kalau memulai dari nol, mungkin lebih baik memakai exception, tetapi sulit karena harus kompatibel dengan kode lama
      Jadi ini bukan karena penolakan filosofis terhadap exception, melainkan larangan karena alasan praktis. Katanya, kalau mulai lagi dari awal, pilihannya mungkin berbeda
    • Dokumen ini bukan Google Style Guide, melainkan dokumen Chromium Modern C++ Features. Isinya tidak membahas exception atau hal spesifik per platform
    • Saya sudah grep untuk “exception” dan “Windows”, dan yang muncul hanya pembahasan soal [[no_unique_address]], jadi sepertinya saya melewatkan leluconnya

  • Daftar fitur yang dilarang begitu banyak sampai tampak lebih panjang daripada seluruh fitur C. Sangat berlebihan

    • C++ memang bahasa yang sangat besar

  • Melarang literal u8"..." adalah keputusan bagus. Kalau source-nya sendiri sudah ditulis dalam UTF-8, prefiks itu tidak perlu
    Literal seperti ini terasa seperti solusi yang muncul sebelum masalahnya ada

  • Saya ingin tahu alternatif untuk fitur-fitur yang dilarang. Misalnya, <filesystem> disebut punya dukungan pengujian yang kurang dan celah keamanan

    • Untuk sebagian besar item terlarang, library pengganti ditulis tepat di sebelahnya. <filesystem> tampaknya satu-satunya pengecualian
    • Mungkin ada informasi terkait di dokumentasi pengembang Chromium
    • Biasanya mereka memakai base/files

  • Modules juga dilarang. Rasanya lebih baik kalau mereka saja menyalin sistem modul bahasa D

    • Alasannya adalah dukungan compiler yang belum memadai

  • Daftar larangan ini menunjukkan bahwa konteks lebih penting daripada fitur terbaru. Untuk aplikasi kecil mungkin tidak masalah, tetapi di proyek besar bisa berisiko

    • Inti panduan Google adalah agar orang tetap bisa berkontribusi dengan aman meski bukan ahli bahasa itu sendiri. Jadi tujuannya bukan sekadar skala proyek, melainkan konsistensi organisasi
      Portabilitas lintas berbagai platform juga ikut dipertimbangkan
    • Ada juga banyak implementasi internal yang dipertahankan karena alasan historis atau kompatibilitas. Banyak di antaranya sudah ada sebelum distandardisasi, jadi sulit diganti
    • Saya juga merasa, dibanding mencampur fitur baru di mana-mana, menjaga konsistensi dengan aturan yang sudah ada itu lebih ringan bagi pembaca kode