Por que as ligações estruturadas do C++ 17 não usam{}?



c++17 structured-bindings (4)

@SebastianWahl comentou apenas com um link. Vou resumir rapidamente o conteúdo por trás do link.

A resposta de Chandler Carruth para esta pergunta: youtu.be/430o2HMODj4?t=15m50s

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

está ok com auto . Mas você também pode fazer isso:

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

Então, quando você usa {...} isso se tornaria

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

o que é ruim , porque a peça tuple<int,float,string> {a,b,c} também tem um significado em C ++ e, portanto, seria uma ambigüidade difícil, difícil de resolver.

Eu encontrei a proposta original para ligações estruturadas * C ++ here . Ele propõe uma maneira de vincular facilmente vários valores de retorno, ou seja:

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

Mas agora vejo que todos apontam para a sintaxe da proposta C ++ 17 / C ++ 1z

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

Agora que eu aprendi "listas são escritas {like, this}" vem uma nova sintaxe de lista? Por quê? Qual é o problema com chaves aqui?


Answer #1

A alteração de {} para [] ocorreu depois de Jacksonville e foi feita em resposta aos comentários dessa reunião. Isto é detalhado em p0144r2 , que afirma: "porque é visualmente diferente da sintaxe existente para declarar múltiplas variáveis ​​do mesmo tipo."

Parece que os comentários do NB solicitando uma alteração no uso original de {} não aumentaram o consenso nas reuniões de novembro de 2016, deixando o uso do [] intacto. Pelo menos até a reunião da primavera.


Answer #2

Os Órgãos Nacionais da Espanha e dos EUA propuseram a mudança para a {} sintaxe porque ( P0488R0 ):

A proposta de “ligações estruturadas” usava originalmente as chaves “{}” para delimitar os identificadores de ligação. Esses delimitadores foram alterados para colchetes “[]” sob a afirmação de que eles não introduziram nenhum problema sintático. No entanto, eles acabaram apresentando uma ambigüidade sintática com atributos e lambdas. À luz de várias correções sugeridas, parece que a sintaxe original é mais adequada.

Portanto, ainda existe a possibilidade de acabar com a sintaxe original do C ++ 17 (que eu acredito fortemente ser a preferida pela maioria dos usuários).

Atualização deste relatório de viagem :

A proposta original para declarações de decomposição usava a sintaxe auto {a, b, c}; que foi alterado na última reunião para auto [a, b, c] . Essa mudança foi bastante controversa, e vários comentários pediram para mudar de volta para {} (enquanto outros encorajaram manter o [] ). Existem argumentos técnicos em ambos os lados (a sintaxe [] pode entrar em conflito com os atributos assim que você começar a permitir decomposições aninhadas; a sintaxe {} pode entrar em conflito com a inicialização uniforme se você usar Conceitos na mistura e permitir usar um nome conceitual em vez de auto ) Então, no final, é basicamente uma questão de gosto. Os implementadores do clang relataram que tentaram ambos e descobriram que as ambiguidades são mais fáceis de serem resolvidas com [] . No final, não houve consenso para uma mudança, portanto, o status quo ( [] sintaxe) permanece.


Answer #3

Uma coisa a ser dita para a sintaxe dos colchetes é que ela se parece muito com cláusulas de captura lambda, onde, da mesma forma, você não especifica o tipo de variável, já que auto está implícito. Ou seja

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

Obviamente, não é exatamente a mesma coisa, mas quando você pensa sobre isso como "sintaxe para captura automática ao entender o contexto", ele pode funcionar:

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




structured-bindings