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