C++14のLWG Issueに対応

lang/cpp11/constexpr.md

@@ -131,6 +131,12 @@ constexpr int f(bool b)
 
 
 ## 備考
+### 標準ライブラリ関数への`constexpr`指定
+標準ライブラリの関数に`constexpr`が付くかどうかは、規格が明示的に要求している場合に限られる。処理系が独自の判断で、規格が要求していない標準ライブラリ関数のシグニチャに`constexpr`を付けることは許可されていない。
+
+これは、ある処理系では定数式で使えるが別の処理系では使えない、といった移植性の問題を防ぐためである。
+
+
 ### 浮動小数点数演算での注意
 `constexpr`関数での浮動小数点数は、コンパイル時に実行するとコンパイル環境で計算が行われ、実行時に実行すると実行環境で計算が行われる。これによって、コンパイル時と実行時で、結果が異なる可能性がある。
 
@@ -234,3 +240,5 @@ GCC 5.2、Clang 3.7、Visual C++ 2015時点で、3つともデフォルトは512
     - リテラル型のメンバ変数のみを持つクラスは、`constexpr`コンストラクタを明示的に定義しなくても、リテラル型となる
 - [CWG Issue 699. Must constexpr member functions be defined in the class member-specification?](http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#699)
     - ゼロ割りの扱い、再帰回数の規定
+- [LWG Issue 2013. Do library implementers have the freedom to add `constexpr`?](https://cplusplus.github.io/LWG/issue2013)
+    - C++14で、処理系が規格の要求を超えて標準ライブラリ関数に`constexpr`を付けることは許可されないと規定された。処理系ごとに定数式で使える関数が異なると、移植性のあるプログラムを書けなくなるため

reference/algorithm/nth_element.md

@@ -55,7 +55,7 @@ namespace std {
 
 
 ## 効果
-`nth_element()` を呼び出した後、`nth` が指している位置の要素は、全ての範囲がソートされた場合の位置にある要素になる。そして、`[first,nth)` にあるイテレータ `i` と、`[nth,last)` にあるイテレータ `j` について、`!(*j < *i)` または `comp(*j, *i) == false` になる。
+`nth_element()` を呼び出した後、`nth` が指している位置の要素は、全ての範囲がソートされた場合の位置にある要素になる。ただし`nth == last`である場合、この規定は適用されない。そして、`[first,nth)` にあるイテレータ `i` と、`[nth,last)` にあるイテレータ `j` について、`!(*j < *i)` または `comp(*j, *i) == false` になる。
 
 
 ## 戻り値
@@ -109,5 +109,8 @@ int main()
 - [LWG Issue 2163. `nth_element` requires inconsistent post-conditions](http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2163)
     - C++11まで、この関数を呼び出したあとの状態について「`!(*i > *j)`」と記載していたが、並べ替えには`operator<()`を使用するので、C++14で「`!(*j < *i)`」に訂正。
 - [LWG Issue 2150. Unclear specification of `find_end`](http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2150)
+- [LWG Issue 2339. Wording issue in `nth_element`](https://cplusplus.github.io/LWG/issue2339)
+    - C++14で、`nth == last`の場合には`nth`が指す位置の要素についての規定が適用されないことが明確化された
+    - この修正は欠陥報告(DR)であり、C++98以降に遡及して適用される。`nth == last`は終端イテレータであり指す要素が存在しないため、元の規定はそもそも意味を成さず、処理系は当初から現在の動作を採っていたため
 - [P0574R1 Algorithm Complexity Constraints and Parallel Overloads](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0574r1.html)
 - [P0879R0 Constexpr for `swap` and `swap` related functions](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0879r0.html)

reference/algorithm/partition_copy.md

@@ -50,7 +50,7 @@ namespace std {
 
 
 ## テンプレートパラメータ制約
-- `InputIterator` の value type は `Assignable` で、`out_true` と `out_false` の `OutputIterator` へ書き込み可能で、`Predicate` の引数型へ変換可能であること
+- `InputIterator` の value type は `CopyAssignable` で、`out_true` と `out_false` の `OutputIterator` へ書き込み可能で、`Predicate` の引数型へ変換可能であること
 
 
 ## 事前条件
@@ -134,5 +134,8 @@ odds : 1,3,5,
 - [N2666 More STL algorithms (revision 2)](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2666.pdf)
 - [P0202R3 Add Constexpr Modifiers to Functions in `<algorithm>` and `<utility>` Headers](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0202r3.html)
 - [P0467R2 Iterator Concerns for Parallel Algorithms](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0467r2.html)
+- [LWG Issue 2357. Remaining "Assignable" requirement](https://cplusplus.github.io/LWG/issue2357)
+    - C++14で、要件の名前が、C++98から使われていた`Assignable`から`CopyAssignable`へ改められた
+    - この修正は欠陥報告(DR)であり、C++11以降に遡及して適用される。C++11で名前付き要件を改名した際に本関数への適用が漏れた編集上の誤りの修正であり、要件の内容そのものは変わらないため
 - [LWG Issue 4465. §[alg.partitions] Clarify _Returns:_ element](https://cplusplus.github.io/LWG/issue4465)
     - C++26で、戻り値の`pair`が、それぞれ`out_true`／`out_false`の各出力範囲へコピーされた最後の要素の次を指すイテレータであることが明確化された

reference/atomic/atomic_thread_fence.md

@@ -96,6 +96,13 @@ assert(i == 1 || j == 1); // すなわち、i と j が共に0となることは
 投げない
 
 
+## 備考
+- アトミックオブジェクト`M`に対するアトミック変更`A`・`B`について、以下のいずれかが成り立つ場合、`B`は`M`の変更順序において`A`よりも後に発生する。ここで`S`は[`memory_order_seq_cst`](memory_order.md)操作の全順序である。
+    - `A`が[`memory_order_seq_cst`](memory_order.md)フェンス`X`よりも前に順序付けられており、かつ`X`が`S`において`B`に先行する
+    - [`memory_order_seq_cst`](memory_order.md)フェンス`Y`が`B`よりも前に順序付けられており、かつ`A`が`S`において`Y`に先行する
+    - [`memory_order_seq_cst`](memory_order.md)フェンス`X`・`Y`が存在し、`A`が`X`よりも前に、`Y`が`B`よりも前に順序付けられており、かつ`X`が`S`において`Y`に先行する
+
+
 ## 例
 ```cpp example
 #include <iostream>
@@ -148,6 +155,9 @@ int main()
 
 ## 参照
 - [Implementing Dekker's algorithm with Fences](https://www.justsoftwaresolutions.co.uk/threading/implementing_dekkers_algorithm_with_fences.html)
+- [LWG Issue 2130. Missing ordering constraints](https://cplusplus.github.io/LWG/issue2130)
+    - C++14で、[`memory_order_seq_cst`](memory_order.md)フェンスによる変更順序の制約が整理され、フェンスが片側にのみ存在する場合についても順序が規定された
+    - この修正は欠陥報告(DR)であり、C++11以降に遡及して適用される。元の規定は両側にフェンスがある場合しか扱っておらず、フェンスと[`memory_order_seq_cst`](memory_order.md)操作を混在させたときの順序が規定から抜けていた記載漏れの補完であるため
 - [P3309R3 `constexpr atomic` and `atomic_ref`](https://open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3309r3.html)
     - C++26で`constexpr`に対応した
 - [P3475R2 Defang and deprecate memory_order::consume](https://open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3475r2.pdf)

reference/codecvt/codecvt_utf16.md

@@ -11,11 +11,14 @@ namespace std {
   template <class Elem, unsigned long Maxcode = 0x10ffff,
             codecvt_mode Mode = (codecvt_mode)0>
   class codecvt_utf16 : public codecvt<Elem, char, mbstate_t> {
-    // 未規定...
+  public:
+    explicit codecvt_utf16(size_t refs = 0);
+    ~codecvt_utf16();
   };
 }
 ```
 * codecvt_mode[link /reference/codecvt/codecvt_mode.md]
+* size_t[link /reference/cstddef/size_t.md]
 * codecvt[link /reference/locale/codecvt.md]
 
 ## 概要
@@ -90,5 +93,8 @@ int main()
 
 ## 参照
 - [N2401 Code Conversion Facets for the Standard C++ Library](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2401.htm)
+- [LWG Issue 2229. Standard code conversion facets underspecified](https://cplusplus.github.io/LWG/issue2229)
+    - C++14で、クラス定義が「未規定」ではなく、コンストラクタとデストラクタを持つことが明示された
+    - この修正は欠陥報告(DR)であり、C++11以降に遡及して適用される。利用者がこれらのファセットを構築できることが規定上不明確だったものの明文化であり、処理系は当初からこれらを提供していたため
 - [P0618R0 Deprecating `<codecvt>`](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0618r0.html)
 - [P2871R3 Remove Deprecated Unicode Conversion Facets from C++26](https://open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2871r3.pdf)

reference/codecvt/codecvt_utf8.md

@@ -11,11 +11,14 @@ namespace std {
   template <class Elem, unsigned long Maxcode = 0x10ffff,
             codecvt_mode Mode = (codecvt_mode)0>
   class codecvt_utf8 : public codecvt<Elem, char, mbstate_t> {
-    // 未規定...
+  public:
+    explicit codecvt_utf8(size_t refs = 0);
+    ~codecvt_utf8();
   };
 }
 ```
 * codecvt_mode[link /reference/codecvt/codecvt_mode.md]
+* size_t[link /reference/cstddef/size_t.md]
 * codecvt[link /reference/locale/codecvt.md]
 
 ## 概要
@@ -90,5 +93,8 @@ int main()
 
 ## 参照
 - [N2401 Code Conversion Facets for the Standard C++ Library](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2401.htm)
+- [LWG Issue 2229. Standard code conversion facets underspecified](https://cplusplus.github.io/LWG/issue2229)
+    - C++14で、クラス定義が「未規定」ではなく、コンストラクタとデストラクタを持つことが明示された
+    - この修正は欠陥報告(DR)であり、C++11以降に遡及して適用される。利用者がこれらのファセットを構築できることが規定上不明確だったものの明文化であり、処理系は当初からこれらを提供していたため
 - [P0618R0 Deprecating `<codecvt>`](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0618r0.html)
 - [P2871R3 Remove Deprecated Unicode Conversion Facets from C++26](https://open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2871r3.pdf)

reference/codecvt/codecvt_utf8_utf16.md

@@ -11,11 +11,14 @@ namespace std {
   template <class Elem, unsigned long Maxcode = 0x10ffff,
             codecvt_mode Mode = (codecvt_mode)0>
   class codecvt_utf8_utf16 : public codecvt<Elem, char, mbstate_t> {
-    // 未規定...
+  public:
+    explicit codecvt_utf8_utf16(size_t refs = 0);
+    ~codecvt_utf8_utf16();
   };
 }
 ```
 * codecvt_mode[link /reference/codecvt/codecvt_mode.md]
+* size_t[link /reference/cstddef/size_t.md]
 * codecvt[link /reference/locale/codecvt.md]
 
 ## 概要
@@ -90,5 +93,8 @@ int main()
 
 ## 参照
 - [N2401 Code Conversion Facets for the Standard C++ Library](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2401.htm)
+- [LWG Issue 2229. Standard code conversion facets underspecified](https://cplusplus.github.io/LWG/issue2229)
+    - C++14で、クラス定義が「未規定」ではなく、コンストラクタとデストラクタを持つことが明示された
+    - この修正は欠陥報告(DR)であり、C++11以降に遡及して適用される。利用者がこれらのファセットを構築できることが規定上不明確だったものの明文化であり、処理系は当初からこれらを提供していたため
 - [P0618R0 Deprecating `<codecvt>`](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0618r0.html)
 - [P2871R3 Remove Deprecated Unicode Conversion Facets from C++26](https://open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2871r3.pdf)

reference/condition_variable/condition_variable.md

@@ -22,6 +22,10 @@ namespace std {
 `condition_variable`の適切な利用については、[条件変数の利用方法](/article/lib/how_to_use_cv.md)も参照のこと。
 
 
+## 備考
+- 処理系は、[`notify_one()`](condition_variable/notify_one.md)・[`notify_all()`](condition_variable/notify_all.md)の全ての実行、および[`wait()`](condition_variable/wait.md)・[`wait_for()`](condition_variable/wait_for.md)・[`wait_until()`](condition_variable/wait_until.md)の実行の各部分が、単一の未規定な全順序で実行されるかのように振る舞う。この全順序は「happens before」の順序と一貫している。
+
+
 ## メンバ関数
 
 | 名前 | 説明 | 対応バージョン |
@@ -129,3 +133,6 @@ process data
 
 ## 参照
 - [Condition Variables - Operating Systems: Three Easy Pieces](http://pages.cs.wisc.edu/~remzi/OSTEP/threads-cv.pdf)
+- [LWG Issue 2190. Condition variable specification](https://cplusplus.github.io/LWG/issue2190)
+    - C++14で、条件変数の操作が「ある未規定な全順序」ではなく「happens beforeの順序と一貫した単一の未規定な全順序」で実行されると規定された
+    - この修正は欠陥報告(DR)であり、C++11以降に遡及して適用される。元の規定では複数の全順序が存在しうると読め、待機と通知の順序がプログラムの実行順序と矛盾することを許してしまっていたが、これは矛盾した文言の修正であり、処理系の動作は変わらないため

reference/condition_variable/condition_variable/notify_all_at_thread_exit.md

@@ -47,6 +47,10 @@ namespace std {
 
     通知（`notify_all()`）を先に行い、その後でロックを解放するよう順序が変更された。これにより、`lk`のロック解除を待っている別スレッドは、`notify_all()`の呼び出し完了後にはじめて起床できるため、デタッチされたスレッドで`cond`が破棄されて`notify_all()`がダングリング参照になる競合を避けられる。
 
+## 同期操作
+暗黙に行われる`lk.`[`unlock()`](/reference/mutex/unique_lock/unlock.md)の呼び出しは、現在のスレッドに関連付けられたスレッドストレージ期間を持つ全てのオブジェクトの破棄より後に順序付けられる。
+
+
 ## 戻り値
 なし
 
@@ -142,5 +146,8 @@ data is ready: true
 ## 参照
 - [_at_thread_exit系の関数が存在している理由](/article/lib/at_thread_exit.md)
 - [N3070 - Handling Detached Threads and thread_local Variables](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3070.html)
+- [LWG Issue 2140. Meaning of `notify_all_at_thread_exit` synchronization requirement?](https://cplusplus.github.io/LWG/issue2140)
+    - C++14で、同期の規定が「スレッドローカル変数のデストラクタの完了が`cond`を待っているスレッドと同期する」から「暗黙の`unlock()`がスレッドストレージ期間のオブジェクトの破棄より後に順序付けられる」という形へ改められた
+    - この修正は欠陥報告(DR)であり、C++11以降に遡及して適用される。元の規定は待機側スレッドが起床する条件を`notify_all()`ではなくデストラクタの完了に結び付けており実装不可能であって、処理系は当初から現在の動作を採っていたため
 - [LWG Issue 3343. Ordering of calls to `unlock()` and `notify_all()` in Effects element of `notify_all_at_thread_exit()` should be reversed](https://cplusplus.github.io/LWG/issue3343)
     - C++26で、通知処理の順序が`notify_all()`→`unlock()`へ変更された。デタッチされたスレッドで`cond`が破棄され`notify_all()`がダングリング参照となる競合を避けるためである。この変更は欠陥報告 (DR) であり、C++26より前のバージョンでもコンパイラが早期に対応している場合がある

reference/future/async.md

@@ -76,6 +76,8 @@ namespace std {
 - `policy & launch::deferred`が`0`でない場合、関数オブジェクト`f`をその場では実行せず、遅延状態にする
     - (`DECAY_COPY(std::`[`forward`](/reference/utility/forward.md)`<F>(f))`と`DECAY_COPY(std::`[`forward`](/reference/utility/forward.md)`<Args>(args))...`を[`future`](future.md)オブジェクトとの共有状態に格納する)。
     - この関数の戻り値である[`future`](future.md)オブジェクトの[`get()`](future/get.md)もしくは[`wait()`](future/wait.md)が呼び出されるタイミングで、関数オブジェクト`f`に`args...`を渡して実行する。
+    - 関数オブジェクト`f`の戻り値が、共有状態に書き込まれる。
+    - 関数オブジェクト`f`の内部で例外が投げられた場合は、共有状態に投げられた例外が設定される。
 - 有効な実行ポリシーが指定されていない場合(整数値を`launch`型にキャストするような状況)、その動作は未定義(C++14)。
 
 
@@ -208,6 +210,9 @@ foo() = 3
 - [&lt;future&gt; functions - Microsoft Docs](https://docs.microsoft.com/en-us/cpp/standard-library/future-functions?view=vs-2019#remarks)
 - [P2422R1 Remove `nodiscard` annotations from the standard library specification](https://open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2422r1.html)
     - C++26で`[[nodiscard]]`指定が削除された
+- [LWG Issue 2186. Incomplete action on `async`/`launch::deferred`](https://cplusplus.github.io/LWG/issue2186)
+    - C++14で、`launch::deferred`で遅延実行した場合にも、戻り値と送出された例外が共有状態へ格納されることが規定された
+    - この修正は欠陥報告(DR)であり、C++11以降に遡及して適用される。`launch::async`側にのみ規定があり遅延実行の結果をどう扱うかが規定から抜けていた記載漏れの補完であり、処理系は当初から現在の動作を採っていたため
 - [LWG Issue 2752. Throws: clauses of `async` and `packaged_task` are unimplementable](https://cplusplus.github.io/LWG/issue2752)
     - 実装上必要な内部確保を反映し、`async`が[`bad_alloc`](/reference/new/bad_alloc.md)も送出しうることが規定された
     - この修正は欠陥報告(DR)であり、C++11以降に遡及して適用される。型消去のための内部確保が必要なため元のThrows節は実装不可能であり、処理系は当初から`bad_alloc`を送出しえたため

reference/future/packaged_task/op_call.md

@@ -104,3 +104,5 @@ error!
 
 
 ## 参照
+- [LWG Issue 2142. `packaged_task::operator()` synchronization too broad?](https://cplusplus.github.io/LWG/issue2142)
+    - C++14で、この関数についての同期の規定が削除された。「`future`や`shared_future`のあらゆるメンバ関数の呼び出しと同期する」という規定は、タイムアウトで戻る[`wait_for()`](../future/wait_for.md)や[`wait_until()`](../future/wait_until.md)まで含んでしまい広すぎたため。共有状態そのものの規定で必要な同期は既に保証されている

reference/istream/basic_istream/ignore.md

@@ -80,6 +80,9 @@ TBD
 - C++98
 
 ## 参照
+- [LWG Issue 2085. Wrong description of effect 1 of `basic_istream::ignore`](https://cplusplus.github.io/LWG/issue2085)
+    - C++14で、`n`文字を入力したという終了条件が「`n != numeric_limits<streamsize>::max()`であり、かつそこまでに`n`文字を入力した場合」であると明確化された
+    - この修正は欠陥報告(DR)であり、C++98以降に遡及して適用される。元の文言は「`n != numeric_limits<streamsize>::max()`ならば`n`文字を入力する」という条件文だったため、`n == numeric_limits<streamsize>::max()`のときは前提が偽となって条件が成り立ってしまい、1文字も入力せずに終了すると読めてしまっていた。処理系は当初から意図どおりの動作をしていたため
 - [P1264R2 Revising the wording of stream input operations](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1264r2.pdf)
     - C++23でローカルエラー状態の概念が導入され、入力関数のエラー処理セマンティクスが明確化された
 - [P3223R2 Making std::istream::ignore less surprising](https://open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3223r2.html)