[Question] Should single-argument sender adaptors be sender adaptor closure objects?
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 3/5
- Temps estimé
- 1-3 heures
- Accessibilité débutants
- 25/100
- Type d'issue
- Documentation
- Clarté
- Plutôt claire
- Activité
- Active
- Stack technique
- cpp
- Domaine
- api, documentation
Piste de recherche
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.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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()?
- Langage dominant
- C++
- Étoiles
- 2.5k
- Forks
- 284
- Merge moyen
- 1 j 21 h
- PR mergées (30 j)
- 92
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de NVIDIA/stdexec
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
NVIDIA/stdexec#1751 · 3 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 4/5 1-2 jours Accessibilité débutants 45/100
NVIDIA/stdexec#2415 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 4/5 3-5 jours Accessibilité débutants 25/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 4/5 Plus d'une semaine Accessibilité débutants 18/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 4/5 3-5 jours Accessibilité débutants 18/100
NVIDIA/stdexec#2402 · 3 commentaires ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de NVIDIA/stdexec
Issues similaires
-
libc++ test-suite
Difficulté 2/5 1-3 heures Accessibilité débutants 85/100
llvm/llvm-project#239851 ·
Les mainteneurs répondent en général sous 1 jour
-
Bug
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
scipy/xsf#454 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
bug :bug:
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
Les mainteneurs répondent en général sous 1 jour
-
comp-documentation
Difficulté 1/5 Moins d'une heure Accessibilité débutants 84/100
ClickHouse/ClickHouse#129829 ·
Les mainteneurs répondent en général sous 1 jour
-
feature request Python
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
Les mainteneurs répondent en général sous 2 jours