|
1 | 1 | <?xml version='1.0' encoding='utf-8' standalone='no'?> |
2 | 2 | <!DOCTYPE issue SYSTEM "lwg-issue.dtd"> |
3 | 3 |
|
4 | | -<issue num="4354" status="New"> |
| 4 | +<issue num="4354" status="SG1"> |
5 | 5 | <title>Reconsider `weakly_parallel` as the default `forward_progress_guarantee`</title> |
6 | 6 | <section> |
7 | 7 | <sref ref="[exec.get.fwd.progress]"/> |
8 | 8 | </section> |
9 | 9 | <submitter>Lewis Baker</submitter> |
10 | 10 | <date>25 Aug 2025</date> |
11 | | -<priority>99</priority> |
| 11 | +<priority>3</priority> |
12 | 12 |
|
13 | 13 | <discussion> |
14 | 14 | <p> |
@@ -45,6 +45,37 @@ implementations to be much more aware of the fact that these are the guarantees |
45 | 45 | thus could be more expected to customize the `get_forward_progress_guarantee` query to return the |
46 | 46 | respective values. |
47 | 47 | </p> |
| 48 | + |
| 49 | +<note>2025-10-20; Reflector poll. Status changed: New → SG1</note> |
| 50 | +<p> |
| 51 | +Set priority to 3 after reflector poll. Send to SG1 and LEWG. |
| 52 | +</p> |
| 53 | +<p> |
| 54 | +"If there is a default, it should be the weakest possible one. |
| 55 | +If that is an unfortunate choice I’d rather prefer no default and mandate |
| 56 | +that the query gets implemented. Providing a default which is stronger than |
| 57 | +the weakest possible creates logic errors. Accidentally claiming weaker |
| 58 | +than the actual value is only a performance error." |
| 59 | +</p> |
| 60 | +<p> |
| 61 | +"This is tension between the default being promising the least and |
| 62 | +the default being the most likely thing a user wants to do. |
| 63 | +Assuming the least powerful guarantees unless the user has opted in is safer. |
| 64 | +Changing this choice requires going back to LEWG or SG1." |
| 65 | +</p> |
| 66 | +<p> |
| 67 | +"Plenty of reasonable schedulers are weakly parallel at best. |
| 68 | +It's the right default. If your scheduler offers better than |
| 69 | +that, you would naturally remember to customize it." |
| 70 | +</p> |
| 71 | +<p> |
| 72 | +"It seems that the authors of `run_loop::scheduler` did not naturally remember to customize it. |
| 73 | +It's possible the intent was that `run_loop::scheduler` should not offer better |
| 74 | +than `weakly_parallel` forward progress, but it was not discussed in P2300. |
| 75 | +The absence of an explicit implementation of the query could either be |
| 76 | +intentional or an accidental omission. |
| 77 | +Perhaps this is an indication that there should not be a default forward-progress guarantee for schedulers?" |
| 78 | +</p> |
48 | 79 | </discussion> |
49 | 80 |
|
50 | 81 | <resolution> |
|
0 commit comments