[Question] Should single-argument sender adaptors be sender adaptor closure objects?
Maintainer antworten meist innerhalb von 2 Tagen
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-3 Stunden
- Anfängerfreundlichkeit
- 25/100
- Issue-Typ
- Dokumentation
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- cpp
- Bereich
- api, documentation
Rechercherichtung
The question is about the wording of the C++ draft standard paragraph exec.adapt.obj#4, which says single-argument pipeable sender adaptors are closure objects. Compare it with the range adaptor closure wording in the standard and check how stdexec's single-argument sender adaptors are used with and without parentheses. This needs a decision from the maintainers in the thread, not a patch. Done means the maintainers confirm the intended syntax, and any wording fix they agree on is proposed.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Hi @ericniebler,
I have a question regarding sender adaptors: are single-argument sender adaptors intended to be sender adaptor closure objects?
According to exec.adapt.obj#4 in the current draft standard:
"If a pipeable sender adaptor object accepts only one argument, then it is a pipeable sender adaptor closure object."
If I understand correctly, this implies that single-argument sender adaptors like into_variant, affine, and stopped_as_optional should be piped as sndr | into_variant rather than sndr | into_variant().
In std::ranges, single-argument range adaptors (such as views::all or views::keys) are indeed range adaptor closure objects, piped like rng | views::all. Was this design deliberately adopted for sender adaptors as well, or was this paragraph inadvertently copy-pasted from the range adaptor wording? In other words, is sndr | adaptor intended here, or is this a wording defect and it should have been sndr | adaptor()?
- Vorherrschende Sprache
- C++
- Sterne
- 2.5k
- Forks
- 284
- Ø Merge
- 2 T. 5 Std.
- Gemergte PRs (30 T.)
- 85
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus NVIDIA/stdexec
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
NVIDIA/stdexec#1751 · 3 Kommentare ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 25/100
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 4/5 Über eine Woche Anfängerfreundlichkeit 18/100
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 18/100
NVIDIA/stdexec#2402 · 3 Kommentare ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 12/100
NVIDIA/stdexec#2344 · 4 Kommentare ·
Maintainer antworten meist innerhalb von 2 Tagen
Ähnliche Issues
-
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 68/100
eic/TimeframeBuilder#102 ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 65/100
-
error not reported I/O low priority rt_lib
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 67/100
Maintainer antworten meist innerhalb von 1 Tag
-
[XLA] hlo/pass/README.md says passes implement Run; since the NVI change they implement RunImplOffen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 91/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
objectionary/game-of-life#78 ·