C++標準化委員会の文書のレビュー: P0160R0-P0172R0

P0160R0: Wording for removing defaults for unary folds

fold式からデフォルト値を削除する文面案。

P0162R0: A response to "P0055R0: On Interactions Between Coroutines and Networking Library"

「現在提案中のBoost.Asioベースのネットワークライブラリの状態保持のための動的ストレージは、コルーチンのスタック上に確保すれば高速になるので、規格でそのように規程すべきだ」という提案に対し、「そのような設計は実装の自由度を制限してしまい好ましくない。同等の高速化はBoost.Asioのカスタムアロケーターでも可能で、最近のAsioはデフォルトのアロケーターを使った場合でも最適化を自動的にするようになっているので、規格でもそのように規定しよう」という反論。

P0163R0: shared_ptr::weak_type

shared_ptr<T>に対応するweak_ptr<T>のネストされた型名、weak_typeを追加する提案

shared_ptrからweak_ptrを作るには、weak_ptrの型を具体的に記述する必要があった。これではジェネリックなコードを書きにくいので、N4537ではshared_ptrに対応するweak_ptrを返すunlockというメンバー関数を追加する提案をしたが、これは却下された。

しかし、やはりweak_ptrの型を直接書くのは嫌なので、今度はshared_ptrに対応するweak_ptr型のweak_typeというネストされた型名を追加する。

つまり、以下のようなコードを解決する。

template < typename T >
void f( T & t )
{
    auto sptr = t.get_shared_ptr() ; // 何らかのshared_ptrが返される
    std::weak_ptr<???> wptr = sptr ; // 型がわからない。
}

この問題を解決するために、従来、以下のようなコードが書かれてきた。

template < typename T >
std::weak_ptr<T> unlock( std::shared_ptr<T> const & sptr )
{
    return std::weak_ptr<T>( stpr ) ;
}

template < typename T >
void f( T & t )
{
    auto sptr = t.get_shared_ptr() ; // 何らかのshared_ptrが返される
    auto wptr = unlock(sptr) ;
}

この提案を使えば、以下のように書ける。

template < typename T >
void f( T & t )
{
    auto sptr = t.get_shared_ptr() ; // 何らかのshared_ptrが返される
    auto wptr = typename decltype(sptr)::weak_type(sptr) ;
}

unlockの方がわかりやすい気がするのだが。

P0164R0: Core Motions

Core issuesに対する解決の中で規格入りする準備ができたもの一覧

P0165C++ Standard Library Issues to be moved in Kona

Library issuesに対する解決の中で規格入りする準備ができたもの一覧

P0166R0: Three interesting questions about contracts

関数にprecondition, postcondition, invariantを記述できるcontract機能を使って、どのようにvectorのようなクラスで範囲外チェックを記述できるのかというHerb Sutterの提示した問いに答える文書。

P0167R0: Core "ready" Issues

2015 Kona会議以降に規格入りする準備が整ったcore issueの解決の一覧。

P0169R0: regex with Unicode character types

regexをUnicode(char16_t, char32_t)に対応させるために必要な設計の考察。

char32_tはUnicodeコードポイントをほぼそのまま表現できる。basic_regex<char32_t>を実現するには、<locale>をchar32_tに対応させる必要がある。具体的には、ctype<char32_t>, collate<char32_t>, collate_byname<char32_t>を実装する必要がある。

char16_tの方は、char32_tのように実装さえすれば動くわけではない。UTF-16にはサロゲートペアが存在するので、char16_tの一つのオブジェクトは1文字を表現しない場合がある。しかし.(dot atom)とか\S(predefined character class)はサロゲートペアの片割れにマッチしてしまう。サロゲートペアがあるため、char16_tは<locale>をサポートできない。

UTF-16ではなく、UCS-2(サロゲートペアのない16bit固定長Unicode符号。BMPだけをサポートしたもの)をサポートするという案は採用できない。なぜならば、UCS-2はすでにISO/IEC 10646においてdeprecated扱いされているため、今から発行する規格がUCS-2だけをサポートするというのはありえない。

ではどうするのか。basic_regex<char16_t>は提供せず、char16_tとchar32_tを相互変換するイテレーターを提供するという案がある。

他には、char16_tは、現行のbasic_regex<char>と同じく、可変長エンコードをそのまま突っ込んだものとみなし、特に何も対応せずそのまま提供するという案もある。この案を採用する場合、Unicodeに関してはchar32_tに変換した上でbasic_regex<char32_t>を使うべきだ。

筆者の意見では、UTF-8, UTF-16, UTF-32を簡単に変換できる関数と、相互に通過的に変換するイテレーターを提供した上で、正規表現を使いたければbasic_regex<char32_t>に一本化する方法がいいと思う。

P0170R0: Wording for Constexpr Lambda

constexpr lambda式の文面案。

auto f = []( int x ) { return x ; } ;
constexpr int i = f(0) ; // OK

P0171: Response To: Resumable Expressions P0114R0

Resumable Expressionに対して寄せられた懸念事項に答える文書。

言語規格がスケジューリングまで定めるべきではないという意見に対しては、提案しているのはシンタックスシュガーだけで、スケジューリングの詳細はライブラリが実装すると回答。

resumable関数を呼び出す際にawaitを書き忘れると、実に不具合箇所を特定しにくい不具合の元になるという意見に対しては、現在提案中の戻り地を無視すると警告する[[nodiscard]]のような属性を提案すればよいと回答。

P0172R0: Abominable Function Types

C++の型システムには、コンパイラー開発者とメタプログラマーしか知らない闇がある。Abominable functionと名付けられた型のことだ。

abominable functionとは、CV修飾やリファレンス修飾された関数型のことだ。

using regular = void () ;
using abominable = void () const volatile && ;

非メンバー関数はCV修飾やリファレンス修飾することはできない。しかし、関数型はCV修飾、リファレンス修飾ができてしまう。

このようなabominable function型は、ほとんど利用価値がないが、traitsを実装する際に個別に対応しなければならないため、問題になる。

このAbominable functionをどうにかしようと問題提起する文書。