Immutype упростит работу с неизменяемыми типами данных

[gdt]

Интересный проект, но использовать его я конечно не буду :)

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

Для прототипирования и/или как кристаллизация устоявшихся подходов в ваших проектах в отдельный нугет - очень даже неплохо, уверен, что найдёт своё применение. Поставил звезду на гитхабе :)

[NikolayPyanikov]

Спасибо за позитивный комментарий :)

[chersun]

Удалено

[NikolayPyanikov]

Слишком краткий вопрос :) ... не могу угадать из 3-х слов

[chersun]

Нельзя комментировать не дочитав до конца. Был не прав, статья на всё ответила ближе к концу.

[DistortNeo]

А почему параметр не передаётся как in? JIT-компилятор не настолько умный, и каждая передача структуры будет сопровождаться её копированием.

Ну и преимущество оператора with: можно менять сразу несколько полей за раз.

[NikolayPyanikov]

А почему параметр не передаётся как in? JIT-компилятор не настолько умный, и каждая передача структуры будет сопровождаться её копированием.

Спасибо за идею, добавлю в ближайшее время, и напишу бенчмарки

Ну и преимущество оператора with: можно менять сразу несколько полей за раз.

Согласен

[NoofSaeidh]

Если это генератор кода, то может лучше использовать именованные необязательные параметры? Как раз позволит сразу все поля инициализировать.

new Person().With(name: "John", friends: new List<Person>(..))

[NikolayPyanikov]

С версии 1.0.3 для C# 7.2+ для struct и record struct используется модификатор параметра in

[mayorovp]

То есть вы сломали обратную совместимость даже не в минорной версии, а просто в патче?

[NikolayPyanikov]

Компиляция не сломана, код работает также, за исключением прироста производительности, количество скачивания пока незначительное. Если вы уже активно используете Immutype, и ваш код теперь сломан используйте пока зависимость с предыдущей версией и будет время решить как лучше поступить.

[NikolayPyanikov]

Ну и преимущество оператора with: можно менять сразу несколько полей за раз.

Да вот ещё подумал, что ни что не мешает использовать with вместе с Immutype

[OkunevPY]

Код от этих нововведений читабильнее не стал. Если вам понадобилось менять не изменяемое и это делаеться через копии объектов, то в проекте явно что-то идёт не по плану. Оптимальный код всегда в простой и доброй, старой, самой первой спецификации языка, научитесь писать на ней, никакие обёртки будут не нужны.

[NikolayPyanikov]

Код от этих нововведений читабильнее не стал.

Читабелность – это конечно же очень субъективно.

Если вам понадобилось менять не изменяемое и это делаеться через копии объектов, то в проекте явно что-то идёт не по плану.

Immutype создает методы что бы сделать модифицированные копии и ни в коем случае не пытается менять оригиналы объектов. На похожем API, например, построен Roslyn.

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

Возможно, Immutype поможет сэкономит время, если человек делает подобные вещи вручную. Если не делает, то конечно же ему и не нужен Immutype. Я пытаюсь тратить побольше времени на изучение.

[aamonster]

Вопрос: а компилятор C# (с оператором with или без него) умеет оптимизировать создание таких копий? В смысле, если оригинал больше не используется – модифицировать его и возвращать вместо копии?
Грубо говоря, в вызове new Person().WithName("John").WithAge(15) не создавать три разных объекта, а создать только один с нужными полями.

[DistortNeo]

Нет, не умеет. Компилятор C# только транслирует C#-код в MSIL лишь с небольшим числом оптимизаций. Проверяется просто: через декомпиляцию. Оптимизации также может применять JIT-компилятор, но он вынужден компилировать код быстро, и потом на подобные фокусы тоже не способен.

[NikolayPyanikov]

Слишком умно для него. Скорее всего, даже старые версии .NET заинлайнят вызовы WithName и WithAge - инструкций там совсем мало и добавлен атрибут для агрессивного инлайнинга, а в .NET 6 его еще более агрессивным сделали :) Фактически останется только вызов конструкторов, а это ну оооочень быстра операция в .NET. Также можно убрать проверки аргументов для случаев, когда включена нулабилити, но они полезны, а прирост производительности будет минимальным. Я сделаю бенчмарки что бы сравнить с with. Но как я уже упомянул, ни что не мешает миксовать ключевой слово with и вызовы сгенерированных статических методов там где удобно для записей. Остальные типы можно использовать через статические методы.

Добавил еще поддержку универсальных типов со всеми возможными ограничениями параметров типа

[aamonster]

Если не лень бенчмарк делать – попробуйте ещё для сравнения на мутабельных типах, с fluent-синтаксисом (когда withName модифицирует объект и возвращает его же).

Только тест надо делать длинный, чтобы увидеть влияние работы GC.

[NikolayPyanikov]

Добавил бенчмарки