Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, _NN_, Вы писали:
_NN>>Начинать сегодня писать код сервисов на .NET это действительно будет странным выбором. _NN>>Экосистема Go ушла далеко вперёд.
Ф>Смотря что писать: го — очень слабенький, невыразительный язык, почти ассемблер.
Слабенький, да.
Но у него есть другие преимущества.
Здравствуйте, _NN_, Вы писали:
_NN>Вынужден согласиться. _NN>Для Линукс сегодня я есть Rider, но это не от MS. _NN>От MS есть только VSCode и закрытый DevKit.
Здравствуйте, novitk, Вы писали:
N>Здравствуйте, _NN_, Вы писали:
_NN>>Слабенький, да. _NN>>Но у него есть другие преимущества.
N>Раньше был АОТ, а сейчас где преимущества?
Я про преимущества Go.
Native .NET недостаточно зрел, чтобы можно пользоваться в продакшне.
У него достаточно ограничений.
Здравствуйте, _NN_, Вы писали:
N>>Раньше был АОТ, а сейчас где преимущества? _NN>Я про преимущества Go.
И я про них. Недостатков по сравнению с .NET там полный набор.
_NN>Native .NET недостаточно зрел, чтобы можно пользоваться в продакшне. _NN>У него достаточно ограничений.
Все эти ограничения есть и в GoLang. Он что умеет C++ CLI или runtime Linq code gen?
Здравствуйте, novitk, Вы писали:
N>Здравствуйте, _NN_, Вы писали:
N>>>Раньше был АОТ, а сейчас где преимущества? _NN>>Я про преимущества Go. N>И я про них. Недостатков по сравнению с .NET там полный набор.
_NN>>Native .NET недостаточно зрел, чтобы можно пользоваться в продакшне. _NN>>У него достаточно ограничений. N>Все эти ограничения есть и в GoLang. Он что умеет C++ CLI или runtime Linq code gen?
Так дело не в том, что он умеет или нет.
Дело в библиотеках, которые адаптированы под эти ограничения.
В .NET не все библиотеки могут так работать. Ну и количество работы не так уж мало.
А в Go изначально так нельзя и поэтому каждый решает проблему как может.
Бесспорно у нас будет .NET Native 20 , где всё будет работать, а Go уже сегодня работает десяток лет.
Здравствуйте, _NN_, Вы писали:
_NN>Дело в библиотеках, которые адаптированы под эти ограничения. _NN>В .NET не все библиотеки могут так работать. Ну и количество работы не так уж мало.
+1. Надо бы флажок в nuget добавить — AOP supported.
Today you may have an extension method that follows the pattern:
public static class Extensions
{
public static IEnumerable<int> WhereGreaterThan(this IEnumerable<int> source, int threshold)
=> source.Where(x => x > threshold);
}
The receiver is the parameter prefaced by the this keyword — source in this case. Property declarations do not have a similar location to declare the receiver. Thus, C# 14 introduces extension blocks. These are blocks with a scope that exposes the receiver to its contained members. If we switch the WhereGreaterThan extension method to the new syntax and add an IsEmpty property the extension block would be:
public static class Extensions
{
extension(IEnumerable<int> source)
{
public IEnumerable<int> WhereGreaterThan(int threshold)
=> source.Where(x => x > threshold);
public bool IsEmpty
=> !source.Any();
}
}
To use these members, you just call them:
var list = new List<int> { 1, 2, 3, 4, 5 };
var large = list.WhereGreaterThan(3);
if (large.IsEmpty)
{
Console.WriteLine("No large numbers");
}
else
{
Console.WriteLine("Found large numbers");
}
Generics are supported and the resolution rules are the same as for extension methods. For example, you could make WhereGreaterThan and IsEmpty generic:
extension<T>(IEnumerable<T> source)
where T : INumber<T>
{
public IEnumerable<T> WhereGreaterThan(T threshold)
=> source.Where(x => x > threshold);
public bool IsEmpty
=> !source.Any();
}
The constraint to INumber<T> allows the greater than operator to be used.
Static methods and properties don't have a receiver, so the extension block list the type without a parameter name:
extension<T>(List<T>)
{
public static List<T> Create()
=> [];
}
Extension blocks can seamlessly coexist with the extension methods you have today. There's no requirement to switch to the new syntax — both execute in exactly the same way. Just add extension blocks to the static classes that contain your existing extension methods.
The choice is entirely yours. If you prefer to leave your existing extension methods untouched, you absolutely can. But if you’d rather update your code for a consistent look and take advantage of the new syntax, that option is available too. And with tools like Visual Studio, converting to your preferred form has never been easier!
You'll see more extensions in upcoming previews, but we'd love to hear your feedback, so join the team and others in the community in the discussion Extensions.
Null-conditional assignment
Null-conditional assignment assigns a value to a property or field only if the containing instance exists. Imagine you have a code similar to:
public class Customer
{
public string Name { get; set; }
public int Age { get; set; }
}
public class UpdateCustomer
{
public static void UpdateAge(Customer? customer, int newAge)
{
if (customer is not null)
{
customer.Age = newAge;
}
}
}
You can simplify the UpdateAge method:
public static void UpdateAge(Customer? customer, int newAge)
{
customer?.Age = newAge;
}
If the customer is not null, Age will be updated. If customer is null, nothing will happen.
The IDE will help you by recommending this change via a lightbulb.
We'd love your feedback on this feature so join us and others in the community in the discussion on Null-conditional assignment.
и солнце б утром не вставало, когда бы не было меня
Table of Contents:
What’s New in .NET 10: Overview
Key Features and Essential Enhancements of .NET 10
How Can You Migrate to .NET 10 From Previous Versions?
End Note
Здравствуйте, Serginio1, Вы писали:
S>Thus, C# 14 introduces extension blocks.
Какая же дичь... Какой-то блок внутри класса, чтобы сэкономить на спичках.
Не знаю насколько реализуемо, но удобнее было бы что-то типа:
public static class Extensions extend IEnumerable<int>
{
public IEnumerable<int> WhereGreaterThan(int threshold)
=> this.Where(x => x > threshold);
public bool IsEmpty
=> !this.Any();
}
}
Их этот блок extension внутри класса как-то так себе выглядит и больше походит на высасывание синтаксического сахара, чтобы было.
S>Null-conditional assignment
Тоже как-то такое себе. По-моему это не такой уж частый случай, чтобы нужно было оптимизировать в плане написания.
А вот с поисками багов подозреваю, что будут проблемы.
Имелся опыт на проекте, где любили наркоманские свойства вида:
public int Value
{
get { CalcValue(); }
set {}
}
и:
public int Value
{
get { return _value; }
set
{
if (value < 0) return;
_value = value;
}
}
Меня это дико бесило и переделывал нормально, где дотягивались руки (периодически выплывали баги, т.к. разработчики по привычке не смотрели что у свойства пустой сеттер или он не всегда значения меняет, а потом удивлялись чего это они записывают в него одно значение, а фактически оказывается другое).
Тут конечно не такая наркомания, но сомневаюсь, что предлагаемая конструкция будет правильно читаться и не получится так, что ей просто NRE заглушится и ошибка тихо улетит куда-то дальше.
Статья какое-то рекламное говно, простите. Похоже просто сгенерирована чатГПТ.
Все перечисленные фичи взяты еще с .net8.
Из десятки ничего собственно нету.
Здравствуйте, BlackEric, Вы писали:
BE>Вот не плохая статья о нововведениях.
Без комментариев Как можно рекомендовать что-то, как "не плохое" даже не разобравшись?
Before:
var numbers = new List { 1, 2, 3, 4, 5 };
After (.NET 10 with C# 14):
var numbers = [1, 2, 3, 4, 5];
Приведённый выше для C#14 код не компилируется и не должен. Пока что collection expressions что назывется только target-typed, то есть должен быть известен тип, в который выражение необходимо преобразовать. Планов изменить это в C#14 пока нет.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Codealot, Вы писали:
C>Изначально, приоритет отдавался простоте кода и удобству, а не скорости.
Ну или просто не осилили по началу. А потом конкуренты стали на пятки наступать.
C>А сейчас они делают оптимизации в ущерб нужным вещам, которые никак не могут сделать уже почти десяток лет.
Это что же такого важного никак не могут реализовать?
Я вот только закрытие АлгТД могу вспомнить. И вряд ли это из-за того, что на оптимизации переключились.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _NN_, Вы писали:
_NN>Ну во первых об этом уже писали и не раз.
Второй ссылки нет, а первая какие-то спекуляции.
_NN>Были у них утилиты на .NET Framework, которые перевели на .NET, но тут выяснилось, что он не является частью ситсемы и поэтому стартует гораздо медленней. _NN>В последних .NET улучшили это дело с Ready2Run и следующим шагом работают над Native AOT, но когд это будет реально готово в производстве никто не знает. _NN>Посему решили, что раз это утилиты и не что-то мегасложное можно и переписать на Rust, тем более когда такое движение вокруг языка. _NN>Что там дальше с этим я не в курсах, не интересовался.
Ну т.е. мелкую утилиту переписали, а ты уже далеко идущие выводы сделал?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _FRED_, Вы писали:
_FR>Приведённый выше для C#14 код не компилируется и не должен. Пока что collection expressions что назывется только target-typed, то есть должен быть известен тип, в который выражение необходимо преобразовать. Планов изменить это в C#14 пока нет.
Спакуха. К C# 20 в МС на Расте напишут ИИ, который прочтёт исходники Немерла из 2005 года и реализует в C# 20 вывод типов из использования.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _FRED_, Вы писали:
_FR>>Приведённый выше для C#14 код не компилируется и не должен. Пока что collection expressions что назывется только target-typed, то есть должен быть известен тип, в который выражение необходимо преобразовать. Планов изменить это в C#14 пока нет.
VD>Спакуха. К C# 20 в МС на Расте напишут ИИ, который прочтёт исходники Немерла из 2005 года и реализует в C# 20 вывод типов из использования.
Ну вот переменная может быть списком и массивом.
var numbers = [1, 2, 3, 4, 5];
затем я вызываю интеллисенс numbers.
Подсказка должна показывать свойства и методы списка и массива.
Кстати а как в TypeScript с объединениями
let id : number | string;
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Ну вот переменная может быть списком и массивом. S>
S>var numbers = [1, 2, 3, 4, 5];
S>
В Шарпе? Не может.
S> затем я вызываю интеллисенс numbers. S> Подсказка должна показывать свойства и методы списка и массива.
S>Кстати а как в TypeScript с объединениями
S>
S>let id : number | string;
S>
Ты тёплое с мягким путаешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Как можно рекомендовать что-то, как "не плохое" даже не разобравшись? 
