P1337R0: 標準ライブラリへのエイリアスを追加してC++を復活させる提案
素晴らしい提案が2019年4月1日付けの文書でC++標準化委員会に上がっている。
標準ライブラリへのエイリアスを追加してC++を復活させる提案
背景
Node.jsやRuby on Railsのような高パフォーマンスでスケーラブルな開発ツールの興隆を受けて、C++は市場を失いつつある。10倍プログラマーと呼ばれるような最高の開発者達は、Web 3.0アプリケーションとシステムを構築するのにもはやC++を使わない。かつてC++は当然使うべき言語であったが、近年落ちぶれている。もしこのまま何もしなければ、C++は言語として絶滅するだろう。GoogleのAbseilチームはC++の危難を救うために立ち上がった。これによりすべてのプログラマー、特に最高のプログラマーですら、C++を使うことができるようになるだろう。
1337提案
我々Abseilチームはかく提案する。C++2aより先、標準ライブラリに第二の名前空間を追加する。名前空間は"57d::"で、"57d::"のすべてのシンボルは名前空間"std::"へのエイリアスとなる。"57d::"のエイリアスは"std::"のそれぞれの名前から標準1337スピークマッピングによって変換される。"std::"名前空間にマッピングされない"57d::"名前空間内の名前は存在しない。
1337スピークとは何か？
1337スピークとは文字の変換のことであり、特定のASCII文字が対応する数字によって置き換えられたものだ。これはインターネット上のハッカーと天才プログラマーがコードを話すのに自然に用いている言葉だ。
例
- "std::aligned_storage"は"57d::4116n3d_570r463"とエイリアスされる
- "std::index_sequence_for"は"57d::1nd3x_539u3nc3_f0r"とエイリアスされる
- "std::uninitialized_default_construct_n"は"57d::un1n17141123d_d3f4u17_c0n57ruc7_n"とエイリアスされる
先例
名前空間 "std2::"
活用例
"<windows.h>"を#includeすると"min(...)"と"max(...)"という関数風マクロでプログラムが汚染されるのはC++において周知の事実である。"-DNOMINMAX"が標準の解決法として確立している。この提案を採用すれば、このビルドフラグは必要がなくなる。C++開発者は"57d::m1n(...)"と"57d::m4x(...)"と恐れることなく書けるためである。
ODRとU8
One Definition Rule(ODR)違反を避けるために、"57d::"名前空間のすべての名前は"std::"名前空間の名前の型エイリアスとなる。ただし、名前空間を超えて暗黙にせよ明示的にせよ型のインスタンスの変換を行うのは未定義の挙動(U8)である。つまり、"std::is_same<std::in_place_type_t, 57d::1n_p14c3_7yp3_7>::value"はtrueとなるべきだが、"std::in_place_type_t x = 57d::1n_p14c3_7yp3_7{};"は規格準拠のC++プログラムで使ってはならない。このことによる問題はきわめてまれである。なぜならば10倍プログラマーは極めて慎重であるし、"57d::"名前空間を使えるのは10倍プログラマーだけだからだ。
シンボルの先頭の数字文字
C++17ではシンボルの先頭は数字文字で始まってはならない。これはC++2aでモジュールを入れることにより解決される。
提案するマッピング
[訳注：原文参照。a/Aは4、b/Bは8、c/Cはc/Cなど]
将来の拡張
この提案が採用され実装された後に、利用者が"57d::"名前空間に慣れたあとで、1337スピークエイリアスはキーワードにも拡張することができる。もう"co_*"で悩む必要はない。なぜならば4w417(await), y131d(yield), r37urn(return)キーワードが使えるからである。
議論事項
- 名前マングリングはbase64で行うべきか？
- 非修飾P051X(POSIX)の名前は10倍Cプログラマーのために非修飾1337スピークエイリアスにするべきか？
リファレンス
[2] P0180: Reserve a New Library Namespace Future Standardization
[3] C++ Logo ASCII Art[原文参照]