Превращаем C# в Python, JavaScript и F#

[@Popou]

Оххх сколько хауса будет, наверное появиться анализаторы запрещающие создавать расширение операторов для встроенных классов, ну или вообще запретят расширять операторы

[@simplepersonru]

> сколько хауса

p.s. хаоса, но мой комент только ради спойлера

[@VBDUnit]

Артхауса же. А вообще штука годная, даже не для артхаусного кода. Наконец‑то можно будет сократить пепекторы до вменяемого размера

[@withkittens]

ну или вообще запретят расширять операторы

Нет, конечно. Extension operators - это не "случайно так получилось, что теперь с этим делать?", а фича.

[@eeeeeeeeeeee]

В контексте file-based apps (https://habr.com/ru/articles/965532/, https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/tutorials/file-based-programs) выглядит очень интересно. Возможно, некоторые команды переедут с bash / python на c#. Осталось только дождаться, когда умельцы напишут nuget-пакеты со всеми утилитами

Но если честно, есть некоторое ощущение хаоса. Все эти shell-штуки не сочетаются с "нормальной" разработкой. Очень странный курс развития выбрали майкрософты

[@Gromilo]

Видимо слава питона не даёт покоя. Тоже хотят, чтобы программы распространялись копипастой

[@iamkisly]

Слишком долго dotnet был нишевым windows only решением, теперь им "надо бежать в двое быстрее, чтобы оставаться на месте" и хорошо что у кампании есть на это деньги

[@voroninp]

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

[@maxcat]

Давно могли бы на ps переехать, если бы хотели

[@roqin]

Ну discriminated unions вроде в какой-то следующей версии обещают. Может быть.

[@Gromilo]

Мы вот для коллекции используем линку через методы расширения, а для одиночных значений так нельзя :(

Поэтому написал свой Pipe оператор.

Выглядит так: `order?.Pipe(ExtractData) ?? EmptyData();`

[@voroninp]

Так нельзя — как именно нельзя?

[@Gromilo]

Допустим, есть функция ToDto.

Для коллекции я могу сделать orders.Select(ToDto), а для одиночного значения ничего такого нет, будь добр вызывать ToDto(order).

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

[@voroninp]

Эм, а что мешает сделать метод расширение для Order'а?

[@Gromilo]

В этом конкретном случает ничего не мешает, это была иллюстрация.

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

[@voroninp]

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

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

Я, видимо, что-то из контекста упускаю, поэтому всё равно не улавливаю проблему. Можете как-то переформулировать?

[@Gromilo]

Так для коллекций уже кем-то написана куча метдов-расширений которые коллекцию и возвращают

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

Если у меня только 1 элемент xxx, то я так не могу, т.к. никто не написал готовых метод, и приходится писать свой. Выглядит не консистентно.

А ещё лучше иметь на уровне языка поддержку pipe оператора, чтобы отладка нормально работала.

[@withkittens]

т.к. никто не написал готовых метод, и приходится писать свой.

Написали. Не в стандартной библиотеке, но есть несколько функциональных либ для .NET.

Но вообще Pipe/Select/Map элементарно пишется самостоятельно. Да, нужно написать, но ведь один раз всего.

[@CitizenOfDreams]

Дисклеймер: Я не призываю никого писать такой код.

Если в языке есть возможность писать такой код - кто-то будет писать такой код.

[@equmag]

extension members просили довольно давно и это отличное нововведение, хотя два года я их и не ждал. Возможность расширять свойства и статические классы (вроде Math) также даёт много возможностей, которые я весьма приветствую. Уже печально известный .IsNullOrEmpty в виде свойства разойдется наверно по тысячам кодовых баз.

По некоторой причине есть категория людей, которая катастрофически не хочет давать разработчикам новую силу, потому что найдется тот, кто применит ее во зло. Видимо стакан у некоторых людей всегда наполовину пуст

[@withkittens]

Уже печально известный .IsNullOrEmpty в виде свойства 

Не работает это, компилятор резолвит "".IsNullOrEmpty как method group.

[@iamkisly]

Да как обычно сейчас github переполнится шиткодом, как и при введении предыдущих фич.. все ж захотят попробовать. А затем на этом будет обучаться copilot, лол