Здравствуйте, VladD2, Вы писали:

VD>Что за splatting?

var t = (int a, int b) => new (int x, int y) {x = a, y = b};
t(t(1,2)); // splatting;

VD>ПМ — это хорошо, но проблем, вызванных тем что в кортежах отсутствуют имена, он никак не решает.
Мы же прекрасно понимаем, что у элементов кортежа нет имен просто в силу их (кортежей) принципиальной структурной типизации. При номинативной типизации — это будут уже не кортежи, а рекорды.

VD>Имена переменных, при декомпозиции кортежей, придется задавать вручную.
Кхм... как бы это вообще нормально, что "проблема" интерпретации данных, типизированных структурно, она на стороне интерпретатора целиком. Что тут такого-то? В противном случае, мы меняем кортежи на рекорды.

VD>Интеллисенс тут ничем не поможет. А вот если имена будут, то IDE сможет сделать имена для переменны в автомате.
Для того, чтобы IDE могла "сделать имена для переменных в автомате" — вообще не обязательно эти самые имена тащить в систему типов.

VD>В общем, на мой взгляд, очевидно, что от именованных кортежей ака записей польза есть.
Вот и ты туда же... как и авторы "предложения" Ну, или либо чего-то не понимаю.

"Рекорды"... по крайней мере, то, что под этим понимают канонически:

var (int a, int b) A;
var (int x, int y) B;

Тип у A и B — _разный_ — и это важно. В этом — номинативной типизации — основной смысл "рекордов".

Если тоже самое предполагается для "именованных кортежей", то надо просто перестать их называть _кортежами_. Если же для них тип А и тип В будет совпадать, то — кроме потенциальных проблем, с очевидной локальностью таких типов — непонятно, а "зачем вообще козе такой баян" на уровне _системы типов_? Чего мы получаем-то, спуская это на такой уровень? Разве нельзя добиться ровно того же, не затрагивая систему типов вообще?

VD>>>Записи (рекорды) они тоже структурно типизированы в большинстве ФЯ.
G>> Вот только C# к этим ФЯ не относится.
VD>С тех пор как в шарпе пеоявились лямбды — имеет. Сказав А (начав движение в сторону ФЯ) надо говорить и Б (добавлять фичи нужные для удобного программирования в функциональном стиле).
"Да_ладно.жпг". Я, правда, дааавненько ничем серьезным на C# не страдал... но, сдается мне, делегаты и до лямбд структурно типизировались. И совсем не понятно, причем тут типизация лямбд, если в топике речь о несколько другом?

G>>Ну, всё таки парни там не настаивают сильно на номинативной типизации таких "кортежей". С другой стороны, когда я это читаю, у меня создается стойкое ощущение... легкого недоумения — они это серьезно?!
VD>Предложение по "кортежам" есть. О чем ты говоришь я не знаю.
Возможно я смотрел "не на тех дроидов", но вот, например, это:

public (int sum, int count) Tally(IEnumerable<int> values) 
{
  ...
}

...

(double sum, long count) weaken = Tally(...); // why not?
(int s, int c) rename = Tally(...) // why not?

в моем представлении, имеет не много общего с номинативной типизацией. Из предложения вообще, имхо, местами весьма трудно понять "чего таки хотим"... какую такую "проблему" решаем


VD>А можно и так:
VD>

VD>(var count, var sum) = Tally(myValues); // Все перепутали, но кто же нас проверит?!
VD>

VD>Или так:
VD>

VD>(var x, var age) = Tally(myValues); // Все перепутали, но кто же нас проверит?!
VD>

?! Если вопрос таки только в этом, то совсем не понятно зачем эту "проблему" решать таким извращенным способом?! Можно подумать, что кто-то вдруг взял — и запретил метаданные в .NET

VD>Вот если бы имена были, то ошибку хотя бы можно было бы выявить.
Начинать надо, наверное с того, что вообще не факт что это "ошибка". Если это таки ошибка, то, я извиняюсь, какого рода?


VD>Да и декомпозиция она ведь место и силы отнимает. Во многих случаях обратиться к полю по имени будет проще.
Вот как раз опыт использования ФЯ богатых на кортежи, показывает, что в большинстве случаев полная структура тебе практически никогда не нужна... ты можешь даже и не иметь представления о ней. Сматчил нужное — остальное в dev\null... даже, когда речь идет всего лишь об одном единственном элементе кортежа.

VD>Не стоит биться с ветряными мельницами. Лучше — не хуже.
Я — глядя на это — не сильно уверен что "это" — таки "лучше".