Почему структурированные привязки C++17 не используют {}?
Я нашел исходное предложение для * структурированных привязок C++здесь. Он предлагает способ легко связать несколько возвращаемых значений, т. е.:
auto {a, b} = minmax(data);
но теперь я вижу, что все указывают на синтаксис предложения c++17/C++1z
auto [a, b] = minmax(data);
теперь, когда я узнал, что " списки написаны { like, this }", появляется новый синтаксис списка? Почему? В чем проблема с фигурными скобками?
5 ответов
Это все еще обсуждается. Трудно быть уверенным, какой синтаксис будет наименее запутанным, учитывая, сколько уже используется для [] и {}.
существует также риск того, что" наименее запутанный "и" самый простой для анализа " будут конфликтовать.
национальные органы из Испании и США предложили вернуться к {}
синтаксис, потому что (P0488R0):
первоначально использованное предложение "структурированные привязки" фигурные скобки "{} " для разграничения идентификаторов привязки. Те разделители были заменены на квадратные скобки "[] " под утверждение, что они не вводили синтаксических проблема. Тем не менее, они оказались ввести синтаксическая двусмысленность с атрибутами и лямбдами. В этот свет различных предлагаемых исправлений, похоже, оригинальный синтаксис более адекватен.
таким образом, по-прежнему остается возможность получить исходный синтаксис для C++17 (который, я уверен, предпочитают большинство пользователей).
обновление отсюда отчет о поездке:
в исходном предложении для декомпозиции объявлений используется синтаксис
auto {a, b, c};
Это было изменено на последняя встреча сauto [a, b, c]
. Это изменение было довольно спорным, и несколько комментариев попросили изменить его обратно на{}
(в то время как другие рекомендуется держать[]
). Есть технические аргументы с обеих сторон ([]
синтаксис может конфликтовать с атрибутами, как только вы начинаете разрешать вложенные разложения;{}
синтаксис может конфликтовать с равномерной инициализацией, если вы бросаете концепции в микс и разрешаете использовать имя концепции вместоauto
), так что в конце концов это во многом вопрос вкус. Разработчики clang сообщили, что они попробовали оба, и обнаружили, что двусмысленности легче работать с[]
. В конце концов, не было консенсуса для изменения, поэтому статус-кво ([]
синтаксиса) остается.
@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++ и, таким образом, будет трудно неясность, трудно решить.
изменение с {} На [] произошло после Джексонвилла и было сделано в ответ на замечания этого совещания. Это подробно описано в p0144r2, который гласит: "потому что он более визуально отличается от существующего синтаксиса для объявления нескольких переменных одного и того же типа."
похоже, что комментарии NB, запрашивающие изменение первоначального использования {}, не увеличили консенсус на совещаниях в ноябре 2016 года, оставив использование [] нетронутым. По крайней мере до весны встреча.
одно можно сказать о синтаксисе квадратных скобок, что он очень похож на лямбда-предложения захвата, где, аналогично, вы не указываете тип переменной, так как авто подразумевается. Т. е.
auto func = [a, b] {}
auto func = [a=1, b=2.0] {}
это явно не то же самое, но когда вы думаете об этом как "синтаксис для автоматического захвата на смысл контекста," он может работать:
auto [a, b] = std::make_pair(1, 2.0);