Почему структурированные привязки C++17 не используют {}?

Я нашел исходное предложение для * структурированных привязок C++здесь. Он предлагает способ легко связать несколько возвращаемых значений, т. е.:

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

но теперь я вижу, что все указывают на синтаксис предложения c++17/C++1z

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

теперь, когда я узнал, что " списки написаны { like, this }", появляется новый синтаксис списка? Почему? В чем проблема с фигурными скобками?

49
c++ c++17 structured-bindings

5 ответов

Это все еще обсуждается. Трудно быть уверенным, какой синтаксис будет наименее запутанным, учитывая, сколько уже используется для [] и {}.

существует также риск того, что" наименее запутанный "и" самый простой для анализа " будут конфликтовать.

20

национальные органы из Испании и США предложили вернуться к {} синтаксис, потому что (P0488R0):

первоначально использованное предложение "структурированные привязки" фигурные скобки "{} " для разграничения идентификаторов привязки. Те разделители были заменены на квадратные скобки "[] " под утверждение, что они не вводили синтаксических проблема. Тем не менее, они оказались ввести синтаксическая двусмысленность с атрибутами и лямбдами. В этот свет различных предлагаемых исправлений, похоже, оригинальный синтаксис более адекватен.

таким образом, по-прежнему остается возможность получить исходный синтаксис для C++17 (который, я уверен, предпочитают большинство пользователей).

обновление отсюда отчет о поездке:

в исходном предложении для декомпозиции объявлений используется синтаксис auto {a, b, c}; Это было изменено на последняя встреча с auto [a, b, c]. Это изменение было довольно спорным, и несколько комментариев попросили изменить его обратно на {} (в то время как другие рекомендуется держать []). Есть технические аргументы с обеих сторон ([] синтаксис может конфликтовать с атрибутами, как только вы начинаете разрешать вложенные разложения;{} синтаксис может конфликтовать с равномерной инициализацией, если вы бросаете концепции в микс и разрешаете использовать имя концепции вместо auto), так что в конце концов это во многом вопрос вкус. Разработчики clang сообщили, что они попробовали оба, и обнаружили, что двусмысленности легче работать с []. В конце концов, не было консенсуса для изменения, поэтому статус-кво ([] синтаксиса) остается.

20

@SebastianWahl прокомментировал только ссылку. Я быстро подытожу содержание ссылки.

ответ Чандлера Каррута на этот вопрос: youtu.be / 430o2HMODj4?t=15m50s

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

С auto. Но вы также можете сделать это:

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

поэтому, когда вы используете {...} это стало бы

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

что это плохо, потому что кусок tuple<int,float,string> {a,b,c} также имеет значение в C++ и, таким образом, будет трудно неясность, трудно решить.

13

изменение с {} На [] произошло после Джексонвилла и было сделано в ответ на замечания этого совещания. Это подробно описано в p0144r2, который гласит: "потому что он более визуально отличается от существующего синтаксиса для объявления нескольких переменных одного и того же типа."

похоже, что комментарии NB, запрашивающие изменение первоначального использования {}, не увеличили консенсус на совещаниях в ноябре 2016 года, оставив использование [] нетронутым. По крайней мере до весны встреча.

9

одно можно сказать о синтаксисе квадратных скобок, что он очень похож на лямбда-предложения захвата, где, аналогично, вы не указываете тип переменной, так как авто подразумевается. Т. е.

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

это явно не то же самое, но когда вы думаете об этом как "синтаксис для автоматического захвата на смысл контекста," он может работать:

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