51 votes

Pourquoi les liaisons structurées C ++ 17 n'utilisent-elles pas {}?

J'ai trouvé la proposition originale pour les liaisons structurées * C ++ ici . Il propose un moyen de lier facilement plusieurs valeurs de retour, à savoir:

 auto {a, b} = minmax(data);
 

Mais maintenant, je vois que tout le monde pointe vers la syntaxe de proposition C ++ 17 / C ++ 1z de

 auto [a, b] = minmax(data);
 

Maintenant que j'ai appris que "les listes sont écrites {comme, ceci}", une nouvelle syntaxe de liste vient-elle? Pourquoi? Quel est le problème avec les accolades ici?

21voto

metalfox Points 1255

Les Instances Nationales de l'Espagne et NOUS avons proposé de revenir à l' {} de la syntaxe parce que (P0488R0):

"Structuré liaisons" proposition initialement utilisé les accolades "{}" pour délimiter la liaison identifiants. Ceux les séparateurs ont été modifiés à crochets "[]" en vertu de la affirmation qu'ils n'introduisent pas de toute syntaxique problème. Cependant, elles s'introduire l'ambiguïté syntaxique avec des attributs et des lambdas. Dans la lumière de diverses corrections suggérées, il semble que le syntaxe d'origine est la plus adéquate.

Par conséquent, il reste encore la possibilité de finir par avoir l'original de la syntaxe de C++17 (qui je crois est préféré par la plupart des utilisateurs).


Mise à jour de ce rapport de voyage:

La proposition initiale de décomposition déclarations utilisé la syntaxe auto {a, b, c}; qui a été changé lors de la dernière réunion de auto [a, b, c]. Ce changement a été assez controversé, et plusieurs commentaires demandé de le modifier pour {} (tandis que d'autres encouragés garder l' []). Il y a des arguments techniques sur les deux côtés ( [] de la syntaxe peut entrer en conflit avec des attributs une fois que vous commencez permettant imbriquée décompositions; l' {} de la syntaxe peut entrer en conflit avec l'initialisation uniforme si vous jetez des Concepts dans le mélange et permettre à l'aide d'un concept-nom à la place de auto), donc au final c'est en grande partie une question de goût. Le cliquetis des exécutants n'a de rapport qu'ils ont essayé les deux, et a trouvé les ambiguïtés être plus facile de travailler avec []. En fin de compte, il n'y a pas de consensus pour un changement, de sorte que le statut quo ([] de la syntaxe).

21voto

Jon Chesterfield Points 872

Ceci est encore en discussion. Il est difficile de savoir quelle syntaxe causera le moins de confusion étant donné le nombre d'utilisations déjà existantes pour [] et {}.

Il existe également un risque de conflit entre "le moins déroutant" et "le plus facile à analyser".

13voto

towi Points 5192

@SebastianWahl ne faisait que des commentaires avec un lien. Je vais résumer rapidement le contenu qui se cache derrière le lien.

Chandler Carruth, la réponse à cette question: youtu.être/430o2HMODj4?t=15m50s

auto [a,b,c] = f();

est ok avec auto. Mais vous pouvez également le faire:

tuple<int,float,string> [a,b,c] = f();

Ainsi, lorsque vous utilisez {...} ce qui allait devenir

tuple<int,float,string> {a,b,c} = f();  //<<< not C++17

ce qui est mauvais, parce que le morceau tuple<int,float,string> {a,b,c} a aussi un sens en C++, et, donc, difficile d'ambiguïté, difficile à résoudre.

10voto

Mikel F Points 2907

Le changement de {} [] s'est produite après Jacksonville et a été faite en réponse à des commentaires de cette réunion. Ceci est détaillé dans p0144r2, qui déclare: "parce que c'est visuellement distincts de la syntaxe pour la déclaration de plusieurs variables du même type."

Il semble que le NB de commentaires de demander un changement de l'origine de l'utilisation de {} n'a pas augmenté à un consensus dans le Nov 2016 réunions, laissant le [] utilisation intacte. Au moins jusqu'à la réunion de Printemps.

3voto

Yam Marcovic Points 1566

Une chose à dire concernant la syntaxe des crochets est qu’elle ressemble beaucoup aux clauses de capture lambda, dans lesquelles, de même, vous ne spécifiez pas le type de variable, car auto est implicite. C'est à dire

 auto func = [a, b] {}
auto func = [a=1, b=2.0] {}
 

Ce n'est évidemment pas exactement la même chose, mais quand on y parle de "syntaxe pour la capture automatique en donnant du sens au contexte", cela peut fonctionner:

 auto [a, b] = std::make_pair(1, 2.0);
 

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X