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

S>А они сами до конца не определились с терминологией. Это не больше, чем предварительные наброски, которые относительно легко поменять.
S>Оно так и с шестым шарпом было, и с await в пятом. Кучу раз спецификацию и синтаксис меняли.

Ну, вот и надо до их ведома довести, что у них смешно получается.

S>По уму рекорды надо пилить одновременно с primary ctor, PM, тюплами, операторами для PM и синтаксическим сахаром для immutable types.

Дык, то что они все это в один релиз впихнули, как бэ, намекает на общность фич.

Я тебе больше скажу кортежи, записи и варианты (будем использовать немерловую терминологию) — это все алгебраические типы и для них есть общая теория на которой и созданы оные типы во всех озвученных мною языках. Так что делать их нужно вместо и по единым стандартам.

Далее, фичи вроде декомпозиции кортежей, оператора is, объявление переменных в кондишене if-а и т.п. — это все вариации на тему паттерн-матчинга. И он опять же тесно завязан на алгебраические типы.

S>Ну и наконец разобраться с тюплами — они всё-таки нужны, или проще будет рекорды до ума довести.

Они уже есть, только без синтаксиса. Сделать для них синтаксис не составит труда. В других языках они не мешают. Так что мое мнение — однозначно делать. Кроме того кортежи отлично подходят для описания сигнатур функций (в которых не важны имена). Любая функция может быть выражена в виде двух кортежей (синтаксис Немерла):

int * int -> bool * int

S>Если отказываться — надо возвращать declaration expressions.

Это что? Возможность вернуть значение из блока кода? Если — да, то это, как раз, фича совершенно независимая и очень нужная (особенно при генерации кода).

В Немерле она выглядит очень просто и элегантно. Любой блок может вернуть значение:

{ def a = 42; a * 2 }

Я бы и в Шарпе сделал так же. За одно исчезла бы необходимость в return-е во многих местах и не нужно было бы делать отдельных правил для лямбд с телами и без.

S>Короче, пока до конца не понятно, во что рекорды в итоге превратятся, а ты уже им название требуешь придумать

Совершенно понятно что они хотят сделать. Лично у меня это вопросов не вызвало. А вот то как они хотя это делать и как они это называют — это угар и стыд.

S>И да, довести очень легко — в issues на гитхабе они активно общаются и отвечают.

Там 100500 "знатоков" и "дезигнеров". Отсюда до них это скорее дойдет.
Ну, и в лом мне много по английски писать, а у них там русскоязычных хватает.


VD>> В F# — discriminated unions.
S>???
S>Мы точно про одно и то же говорим?

Точно. Просто тебе нужно ознакомиться с теорией.

S>record в шарпе — это просто сахар для immutable-типа, боль-менее актуальная спецификация тут. Или я отстал от жизни и они опять всё поменяли?

immutab-ильность — это вопрос вторичный. Он возникает из свойств алгебраических типов (они используются как значения и их изменение приведет к странным эффектам).

Как я понимаю они ввели ключевое слово record для классов с первичным (primary) конструктором. У таких классов есть одна незаметное, на первый взгляд, особенность. Этот самый первичный конструктор проводит соответствие между параметрами этого самого конструктора и полями/свойствами класса. Это дает возможность выражать объект такого типа в виде конструктора. А это, в свою очередь, позволяет производить композицию (создание) и декомпозицию объектов с помощью паттерн-матчинга.

Это же свойство характерно для рекордов (классических, а не по МС), а так же для кортежей (опять же классических).

S>Не, record — это primary ctor + immutable + is_operator + equality operators.

is_operator + equality operators проистекают из наличия того самого первичного конструктора. Именно он описывает структуру. Тогда уж было бы логично вместо этого record использовать имеющееся ключевое слово readonly.

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

Если они рассматривают record именно так как говоришь ты, то это еще одна глупость.

S>Всё вышеперечисленное можно и по отдельности использовать, так что отдельное ключевое слово нужно. Месяц назад обсуждалось, если надо — могу ссылку найти.

Что это?

Как использовать отдельно immutable для всех полей типа?

Как использовать отдельно генерацию оператора is?

Как использовать отдельно автоматическое создание equality-операторов?

S>Только не две, а три. Рекорды в ту же степь на сегодня.

Не. Их "рекорды" — это аналоги case-классов скалы или вхождений вариантов немерла. Тут ты заблуждавшийся.

VD>>2. Допилить рантайм донтета так чтобы он поддерживал структурные типы, т.е. ввести типы считающиеся эквивалентными при совпадении всех их полей.
S>Там куда больше надо сделать.

Ничего там большего делать не надо. Это все отбрехи.

S>Причём как я понял из очень обтекаемых комментариев, на CLR team надежды на этот и следующий релизы нет от слова совсем. То ли ресурсов у них нет, то ли совместимость превыше всего.

Эти уроды уже своими отмазками достали. Что они там вообще делают? На хрен выпускать тучу почти одинаковых ратаймов и посылать на хрент реализацию реально нужных фич? Не фига было декларировать платформу для разных языков, раз у них не хватает таланта и усидчивости для воспроизведения нужных для них фич. Мы не делаем поддержки рекородов (в классическом понимании) именно из-за отсутствия поддержки со стороны рантайма. Не хочется все костылями окружать.

S>Буду рад, если ошибаюсь, но пока так.

Я тоже.

S>Кстати, что-то похожее есть уже, но только в K runtime и только для интерфейсов. Причём их по слухам (совсем слухам, без подтверждений) выпиливают.

Это фигня для поддержки COM-а делалась. Она тут не подходит по указанным тобой причинам. Плюс это все левый хаки, а нужна нормальная поддержка структурных типов в дотнете. Тогда и Тайп Скрипт можно будет реализовать на базе дотнета.

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

А слова про том что "много чего..." — это отбрех. У них 10 лет было и они за эти 10 лет почти ничего не сделали. Если сравнить рантайм от дотнета 2.0 и от 4.5.1, то выясняется, что каких-то серьезных изменений между ними нет. Что они делали эти 10 лет?

S>А они точно нужны, при наличии нормальных рекордов и сахара для разбора рекорда на отдельные переменные? Выставлять кортежи в public api... не нравится мне эта идея.

Я уже говорил. Они уже есть. Нужно только синтаксис добавить. Причем для реализации не нужно менять фреймворк.

VD>>5. Предлагаю добавить дженерики с переменным числом параметров, по анологии с C++ поледних версий.
S>А вот это принципе интересная мысль, но я пока не могу придумать ни одного разумного сценария использования. Можешь привести пример?

Гугли c++ variadic templates.

Самые простые применения — это вместо 100500 Actrion<>, Func<> и Tuple<> заводит по одному типу:

delegate Actrion<... Types>(params Types ... args);

а рантайм уже создает конкретные специализации по необходимости.

ЗЫ

Ну, и до кучи надо ввести замену этому убогому delegate — функциональный тип. Это что-то вроде delegate, но без объявления и совместимы структурно. Тогда все эти убогие Actrion и Func вообще становятся ненужны, так как ссылку на функцию можно описать по месту (синтаксис немерла):

Foo(action : int * string -> void, func : int -> string);