Pourquoi avons-nous besoin nécessite?

L'un des coins de C++20 concepts est qu'il y a certaines situations dans lesquelles vous devez écrire requires requires. Par exemple, cet exemple de [expr.prim.req]/3:

Un nécessite expression peut également être utilisé dans un exige la clause ([temp]) comme un moyen de rédaction ad hoc des contraintes sur le modèle des arguments tels que celui ci-dessous:

template<typename T>
  requires requires (T x) { x + x; }
    T add(T a, T b) { return a + b; }

La nécessite d'abord introduit la exige la clause, et la seconde partie présente le nécessite expression.

Qu'est-ce que la technique la raison derrière le besoin de deuxième requires mot-clé? Pourquoi ne peut-on pas autoriser l'écriture:

template<typename T>
  requires (T x) { x + x; }
    T add(T a, T b) { return a + b; }

(Note: veuillez ne pas répondre que de la grammaire requires c')

  • Semble requires peut être utilisé pour la méthode de la classe de modèle, et il serait "ambigu" template <typename T> struct S {void f(T t) requires requires (T x) {x + x;} { t + t;} };
  • Suggestion: "Est-il rien qui exige exige exige?". Plus sérieusement, j'ai l'intuition que c'est la même raison derrière noexcept(noexcept(...)).
  • Ils disent que "Le nécessite tout d'abord introduit la nécessite de la clause, et la seconde partie présente la nécessite d'expression.", mais ce n'est pas compatible avec la grammaire, ils donnent juste au-dessus
  • Avec noexcept il y a ambiguïté. noexcept(f()) pourrait signifier pour être noexcept si f() prend la valeur vrai ou si f() est noexcept.
  • Bien, alors, n'est-ce pas la même raison ici? Un requires clause peut avoir n'importe quel constexpr prédicat, non?
  • Une raison que je vois pour le faire, c'est de rendre l'analyse plus facile. Lorsque le compilateur voit requires il sait le prochain symbole est l'exigence, de sorte que nous avons besoin de la supplémentaires requires à dire qu'il doit analyser cette exigence ad-hoc exigence.
  • Les deux requires sont des homonymes à mon avis: ils ont le même aspect, sort la même, la même odeur, mais sont intrinsèquement différents. Si je devais proposer un correctif, je vous suggère de renommer l'un d'eux.
  • Apparemment oui, comme l'a démontré par NicolBolas, bien que dans une moindre mesure.
  • co_requires? (Désolé, pas pu résister).
  • Où va la folie arrêter? La prochaine chose que vous savez, nous aurons long long.
  • nécessite nécessaire?" aurait été encore plus allitératifs!!
  • Ce n'est pas un burnination demande lol
  • Il est logique gramatically, bizarrement assez. add<T>() nécessite un T qui exige à son tour la capacité d'être ajouté à d'autres Ts. Ainsi, alors qu'il semble répétitif, c'est logique, si vous pensez à ce sujet assez. (Où "je dois être addable" est l'expression, et "la fonction a besoin de quelque chose qui doit être addable" est la contrainte.)
  • Parce que require nécessite requires requires. Désolé, je ne pouvais pas résister.
  • je ne regarde jamais la parole exiger la même chose de nouveau
  • et puis nous avons modèle des paramètres de modèle...
  • A la question de savoir pourquoi avons-nous besoin nécessite requis requis? (Dang, maintenant, je suis en train de réfléchir buffalo ...)
  • dans l'Ouest-de-l'Angleterre rurale accent on pourrait même dire "Pourquoi ne nous exige exige exige?" 😉
  • Merci pour ce mal de tête... je n'ai pas besoin...
  • Par l'imbrication requires clauses/expressions que vous obtenez de drôles de constructions. void Fn() requires requires () { requires requires () { requires true; }; } {} est une contrainte de fonctionner.

InformationsquelleAutor Barry | 2019-01-15
  1. 76

    C'est parce que la grammaire exige. Il n'.

    Un requires contrainte de ne pas ont pour utiliser un requires expression. Il peut utiliser plus ou moins arbitraire boolean expression constante. Par conséquent, requires (foo) doit être légitime requires contrainte.

    Un requires expression (chose qui teste si certaines choses suivre certaines contraintes) est distincte de construire, il est juste introduit par le même mot clé. requires (foo f) serait le début d'un permis de requires expression.

    Ce que vous voulez, c'est que si vous utilisez requires dans un endroit qui accepte les contraintes, vous devriez être en mesure de faire une "contrainte+expression" hors de la requires clause.

    Alors, voici la question: si vous mettez requires (foo) dans un endroit qui est approprié pour une exige de contrainte... dans quelle mesure l'analyseur avoir à aller de l'avant, on peut comprendre que c'est une nécessite contrainte plutôt qu'une contrainte+expression de la façon dont vous voulez qu'il soit?

    Considérez ceci:

    void bar() requires (foo)
{
  //stuff
}

    Si foo est un type, puis (foo) est une liste de paramètres d'un nécessite d'expression, et tout le {} n'est pas le corps de la fonction, mais le corps de cette requires expression. Sinon, foo est une expression dans un requires clause.

    Eh bien, vous pourriez dire que le compilateur doit juste comprendre ce foo est le premier. Mais le C++ vraiment n'aime pas lorsque l'acte de base de l'analyse d'une séquence de jetons exige que le compilateur comprendre ce que ces identifiants dire avant qu'il peut faire sens des jetons. Oui, le C++ est sensible au contexte, de sorte que cela ne se produise. Mais le comité préfère éviter, lorsque cela est possible.

    Donc oui, c'est la grammaire.

    • Est-il judicieux d'avoir une liste de paramètres avec un type, mais sans nom?
    • Cela me rappelle un answer j'ai écrit où, autant que je peux dire, le compilateur ne peut pas faire sens de ce code avant de déterminer quelle x est. Un autre exemple est l'ADL de travail avec les modèles de fonction seulement si il y a une fonction semblable de modèle portée (démo), sinon l'analyse échoue. Je suis sous l'impression que le lourd contexte de la dépendance est assez commun en C++.
    • Il y a certainement des cas de contexte-dépendance dans le C++ de la grammaire. Mais le comité n'a vraiment essayer de minimiser cela, et ils ne aiment pas l'ajout de plus.
    • Si le contexte est la raison, puis en utilisant le même mot dans les deux contextes, est contraire à l'intention.
    • L'utilisation de if vs if constexpr n'est pas sensible au contexte, car raconter l'une de l'autre se fait facilement en fonction de la séquence de jetons. Pour le jeton de la séquence, un identificateur est juste un identifiant. Si la nature de l'identifiant détermine comment analyser la séquence de jetons, alors vous avez affaire à quelque chose qui est problématique dans l'analyseur. Pas impossible, un peu "sensible au contexte". À l'aide d'un mot-clé, comme ce n'est pas sensible au contexte, à cet égard, car l'endroit où vous utilisez ces mots-clés, définit le contexte.
    • Si requires apparaît après un <> ensemble d'arguments de modèle ou d'après un paramètre de la fonction liste, puis c'est une nécessite de la clause. Si requires apparaît lorsqu'une expression est valide, c'est une nécessite d'expression. Ceci peut être déterminé par la structure de l'arbre d'analyse, pas le table des matières de l'arbre d'analyse (les détails de la façon dont l'identificateur est défini serait le contenu de l'arborescence).
    • Ce que je veux dire c'est que ça pourrait tout aussi bien être par exemple "exige la contrainte".
    • Bien sûr, la nécessite d'expression aurait pu utiliser un autre mot clé. Mais les mots clés ont énorme coûts en C++, car ils ont le potentiel de briser n'importe quel programme utilisé l'identifiant qui est devenu un mot-clé. Les concepts de la proposition qui a déjà présenté deux mots-clés: concept et requires. L'introduction d'un tiers, lorsque le second serait en mesure de couvrir les deux cas, sans grammaire et peu de l'utilisateur confronté à des problèmes, est juste un gaspillage. Après tout, le seul problème visuel, c'est que le mot-clé qui arrive à être répétée deux fois.
    • c'est une mauvaise pratique de toute façon de l'inclure des contraintes de semblable depuis que vous n'obtenez pas de subsomption comme si vous aviez écrit un concept. Donc, en prenant un identificateur pour une faible utilisation non recommandée fonctionnalité n'est pas une bonne idée.
    • En général, vous ne pouvez pas analyser C++ à tous, sans le savoir dont les noms sont les types et les noms des modèles, donc je n'aime pas l'exemple donné. Mais les ambiguïtés sont faciles à trouver: c'est très similaire à la plus délicate à analyser.

    InformationsquelleAutor Nicol Bolas
  2. 57

    La situation est exactement analogue à noexcept(noexcept(...)). Bien sûr, cela sonne plus comme une mauvaise chose que d'une bonne chose, mais laissez-moi vous expliquer. 🙂 Nous allons commencer avec ce que vous savez déjà:

    C++11 a "noexcept-clauses" et "noexcept-expressions." Ils font des choses différentes.

    • Un noexcept-clause dit, "Cette fonction devrait être noexcept quand... (une condition)." Il va sur une déclaration de fonction, prend un paramètre booléen, et provoque un changement de comportement dans la fonction déclarée.

    • Un noexcept-expression dit, "Compilateur, veuillez me dire si (une expression) est noexcept." Il est lui-même une expression booléenne. Il n'a pas de "effets secondaires" sur le comportement du programme — il est juste de demander au compilateur de la réponse à une question oui/non. "Est-ce que cette expression noexcept?"

    Nous peut nest un noexcept-expression à l'intérieur d'un noexceptde la clause, mais en général, nous pouvons considérer cela comme de style de le faire.

    template<class T>
void incr(T t) noexcept(noexcept(++t));  //NOT SO HOT

    Il est considéré comme meilleur style pour encapsuler le noexcept-expression dans un type de trait.

    template<class T> inline constexpr bool is_nothrow_incrable_v =
    noexcept(++std::declval<T&>());  //BETTER, PART 1

template<class T>
void incr(T t) noexcept(is_nothrow_incrable_v<T>);  //BETTER, PART 2

    Le C++2a Projet de Travail a "requires-clauses" et "requires-expressions." Ils font des choses différentes.

    • Un requires-clause dit, "Cette fonction devraient participer à la résolution de surcharge lors de la... (une condition)." Il va sur une déclaration de fonction, prend un paramètre booléen, et provoque un changement de comportement dans la fonction déclarée.

    • Un requires-expression dit, "Compilateur, veuillez me dire si (un ensemble d'expressions) est bien formé." Il est lui-même une expression booléenne. Il n'a pas de "effets secondaires" sur le comportement du programme — il est juste de demander au compilateur de la réponse à une question oui/non. "Est-ce que l'expression bien formée?"

    Nous peut nest un requires-expression à l'intérieur d'un requiresde la clause, mais en général, nous pouvons considérer cela comme de style de le faire.

    template<class T>
void incr(T t) requires (requires(T t) { ++t; });  //NOT SO HOT

    Il est considéré comme meilleur style pour encapsuler le requires-expression dans un type de trait...

    template<class T> inline constexpr bool is_incrable_v =
    requires(T t) { ++t; };  //BETTER, PART 1

template<class T>
void incr(T t) requires is_incrable_v<T>;  //BETTER, PART 2

    ...ou en C++(C ++ 2a Projet de Travail) concept.

    template<class T> concept Incrable =
    requires(T t) { ++t; };  //BETTER, PART 1

template<class T>
void incr(T t) requires Incrable<T>;  //BETTER, PART 2
    • Je n'ai pas vraiment acheter cet argument. noexcept a le problème que noexcept(f()) pourrait dire soit interpréter f() comme une valeur booléenne que nous utilisons pour définir la spécification ou vérifier si oui ou non f() est noexcept. requires n'a pas cette ambiguïté, car les expressions de la vérification de la validité d'ores et déjà être introduit avec {}s. Après, l'argument est fondamentalement "la grammaire dit."
    • Voir ce commentaire. Il semble que le {} sont facultatifs.
    • Le {} ne sont pas une option, ce n'est pas ce que ce commentaire montre. Cependant, c'est un grand commentaire démontrant l'analyse de l'ambiguïté. Serait probablement accepter que les commentaires (avec quelques explications) comme une réponse unique
    • requires is_nothrow_incrable_v<T>; devrait être requires is_incrable_v<T>;
    • merci! fixe.
    InformationsquelleAutor Quuxplusone
  3. 15

    Je pense que cppreference concepts page explique cette. Je peux expliquer avec des "mathématiques" pour ainsi dire, pourquoi ce doit être comme ceci:

    Si vous souhaitez définir un concept, ce faire, vous:

    template<typename T>
concept Addable = requires (T x) { x + x; }; //requires-expression

    Si vous voulez déclarer une fonction qui utilise ce concept, vous le faites:

    template<typename T> requires Addable<T> //requires-clause, not requires-expression
T add(T a, T b) { return a + b; }

    Maintenant, si vous ne voulez pas définir le concept en particulier, je suppose que tout ce que vous avez à faire est de substitution. Prendre cette partie requires (T x) { x + x; }; et remplacer le Addable<T> partie, et vous obtiendrez:

    template<typename T> requires requires (T x) { x + x; }
T add(T a, T b) { return a + b; }

    qui est ce que vous demandez sur.

    • Je ne pense pas qu'est ce qui est demandé pour. C'est l'explication de la grammaire, plus ou moins.
    • Mais pourquoi ne pouvez-vous pas avoir template<typename T> requires (T x) { x + x; } et nécessitent qui nécessitent peut être à la fois la clause et de l'expression?
    • Parce que vous êtes de forcer le compilateur à interpréter une construction comme de l'autre. Un requiresen tant que contrainte clause n'est pas à être un requires-expression. C'est simplement une utilisation possible de l'informatique.
    • Je ne pense pas qu'il y a un peu magique réponse à cette question. C'est juste ambigu, et le compilateur a certaines attentes afin qu'il analyse les choses correctement. Probablement dans la prochaine version C++, si ils trouvent qu'il est de ne pas être ambigu, qu'ils peuvent le supporter.
    • Ce que j'ai été avec mon commentaire est cette réponse juste, explique la syntaxe. Pas de quels raisons techniques, nous avons à requires requires. Ils pourraient avoir quelque chose d'ajouté à la grammaire, afin de permettre template<typename T> requires (T x) { x + x; } mais ils n'ont pas. Barry veut savoir pourquoi ils n'ont pas
    • Je ne pense pas qu'il y est une réponse à cette question. Complètement et totalement ajoute, à partir d'un syntaxiques point de vue (comme Nicol expliqué). Encore une fois, peut-être dans la prochaine version C++ ils permettent et il n'est toujours pas évident de savoir si c'est sans ambiguïté. Je ne suis pas sûr que Barry est de demander à propos de cela.
    • Si nous sommes vraiment jouer trouver-la-grammaire-l'ambiguïté ici, OK, je vais mordre. godbolt.org/z/i6n8kM template<class T> void f(T) requires requires(T (x)) { (void)x; }; signifie quelque chose de différent si vous supprimez l'un de l' requireses.
    • Manqué l'occasion d'utiliser un template template paramètre là, tout en démontrant requires requires

    InformationsquelleAutor The Quantum Physicist
  4. 10

    J'ai trouvé un commentaire de Andrew Sutton (l'un des Concepts les auteurs, qui l'ont mis en œuvre dans gcc) pour être tout à fait utile à cet égard, j'ai donc pensé que je venais de citer ici dans sa quasi-totalité:

    Pas si longtemps exige-expressions (la phrase introduite par la seconde exige) n'a pas été autorisé dans la contrainte des expressions (la phrase introduite par le premier oblige). Il ne pouvait apparaître que dans les définitions des concepts. En fait, c'est exactement ce qui est proposé dans la section de ce papier où cette revendication apparaît.

    Cependant, en 2016, il y avait une proposition pour se détendre la restriction [note de l'Éditeur: P0266]. Note barré du paragraphe 4 de la section 4 du document. Et ainsi est né nécessite.

    De dire la vérité, je n'avais jamais réellement mis en œuvre cette restriction dans GCC, de sorte qu'il a toujours été possible. Je pense que Walter peut-être découvert et trouvé utile, ce qui conduit au papier.

    De peur que quelqu'un pense que je n'étais pas sensible à l'écriture nécessite deux fois, j'ai passé du temps à essayer de déterminer si cela pourrait être simplifiée. Réponse courte: non.

    Le problème, c'est qu'il y a deux constructions grammaticales qui en ont besoin à l'introduction d'après un modèle de liste de paramètres: très généralement une expression de contrainte (comme P && Q) et, occasionnellement, syntaxiques exigences (comme requires (T a) { ... }). Cela s'appelle une demande d'expression.

    La nécessite d'abord introduit la contrainte. La seconde nécessite introduit la demande de l'expression. C'est juste la façon dont la grammaire compose. Je ne trouve pas de confusion à tous.

    J'ai essayé, à un moment donné, à l'effondrement de ces pour un seul exige. Malheureusement, cela conduit à de très difficiles problèmes de l'analyse. Vous ne pouvez pas dire facilement, par exemple si un ( après l'exige désigne un imbriquée sous-expression ou un paramètre de la liste. Je ne crois pas qu'il y est une parfaite homonymie de ces syntaxes (voir la justification de l'uniforme de la syntaxe d'initialisation; ce problème est-il trop).

    Afin de vous faire un choix: faire nécessite d'introduire une expression (comme il le fait maintenant) ou faire introduire un paramétrée liste d'exigences.

    J'ai choisi l'approche actuelle parce que la plupart du temps (comme dans la quasi 100% du temps), je veux autre chose qu'une demande d'expression. Et dans les très rares cas, je ne veux nécessite expression ad hoc contraintes, je n'ai vraiment pas l'esprit en écrivant le mot deux fois. C'est l'indicateur le plus évident que je n'ai pas encore développé suffisamment son abstraction pour le modèle. (Parce que si j'avais, il aurait un nom.)

    Je pourrais avoir choisi de faire de la nécessite d'introduire une demande d'expression. C'est en fait pire, parce que pratiquement tous vos contraintes commencerait à ressembler à ceci:

    template<typename T>
  requires { requires Eq<T>; }
void f(T a, T b);

    Ici, le 2ème exige est appelé un sous-exigence; il évalue son expression (autre code dans le bloc de la nécessite d'expression n'est pas évaluée). Je pense que c'est pire que le statu quo. Maintenant, vous arrivez à écrire nécessite deux fois partout.

    J'ai pu également utiliser plusieurs mots-clés. C'est un problème dans son propre droit---et ce n'est pas seulement vélo effusion. Il y a peut être un moyen de "redistribuer" mots clés pour éviter la répétition, mais je n'ai pas étant donné que la pensée sérieuse. Mais cela ne change pas le fond du problème.

    InformationsquelleAutor
  5. -10

    Parce que vous dites qu'une chose a une exigence de B, et l'exigence de B a une exigence C.

    La chose A dépend de B, qui à son tour nécessite C.

    La "exige" la clause elle-même exige quelque chose.

    Vous avez Une chose (nécessitant B (nécessitant C)).

    Meh. 🙂

    • Mais, selon les autres réponses, la première et la deuxième requires ne sont pas conceptuellement la même chose (l'une est une clause, une sur-expression). En fait, si je comprends bien, les deux ensembles de () dans requires (requires (T x) { x + x; }) ont des significations très différentes (l'extérieur étant facultatif et contenant toujours un booléen constexpr; l'être intérieur d'une partie obligatoire de l'introduction d'une nécessite d'expression et de pas permettant réelle des expressions).
    • Dites-vous que les exigences diffèrent-ils? 😀
    InformationsquelleAutor Lightness Races in Orbit