Какой сахар мне хотелось бы видеть в новых версиях C#

Вас не подвело зрение, мне действительно не хватает кое-какого синтаксического сахара)

Большинство разработчиков знакомы с оператором ??

Он делает эквивалентными две следующие строчки:

return expr is null ? fallbackValue : expr

// ...

return expr ?? fallbackValue

Однако, в моей практике часто встречалась ситуация, когда необходимо было сделать обратный процесс:

return expr is null ? null : GetResult(expr)

Хотелось бы сократить эту запись до одного оператора.

Не важно, как он будет называться, варианты: ?!, ?:, ???

Тогда, сокращение будет выглядеть так:

return expr ??? GetResult(expr)

Priority Queue

В .NET 6 завезли такую настоящую объекто-ориентированную очередь с приоритетами.

Объектно-ориентированная в смысле поддержки своих формальных типовых параметров:

▪️TElement - тип содержимого очереди

▪️TPriority - тип приоритета содержимого очереди

По сути своей, это сортирующая коллекция, в которой приоритет выступает ключом сортировки.

Причём в конструктор очереди, можно передать экземпляр IComparer<T>, чтобы, например, определить направление сортировки:

// сортируем по убыванию некоторой даты
var queue = new PriorityQueue<string, DateTimeOffset>(
    Comparer<DateTimeOffset>.Create((x, y) => y.CompareTo(x)));

queue.Enqueue("abv", DateTimeOffset.UtcNow.Subtract(TimeSpan.FromDays(2)));
queue.Enqueue("ghj", DateTimeOffset.UtcNow.Subtract(TimeSpan.FromDays(3)));
queue.Enqueue("123", DateTimeOffset.UtcNow.Subtract(TimeSpan.FromDays(1)));

while (queue.TryDequeue(out var card, out var addedOn))
{
    Console.WriteLine($"{card}, {addedOn}");
}
// чтение выведет: 123 | abv | ghj

Получается, можно постоянно туда что-то докидывать и получать отсортированные подвыборки, помимо решения задачи приоритизирования.

Из недостатков можно отметить, что класс PriorityQueue<TElement, TPriority> не реализует никаких LINQ интерфейсов, или интерфейсов коллекций, поэтому совместимость с другими API придётся реализовывать самому.

Больше прочитать про внутреннее устройство класса можно в статье Вадима Мартынова на Хабре

Всех с началом рабочей недели!

«Самая зрелая реакция — это радоваться его успеху. Вам следует вознаградить его за производительность и признать его успешность, особенно если это очень качественный сотрудник.

…

Кроме того, мы можете учиться у этих упорно трудящихся людей. Если их показатели крайне высоки, узнайте, как им это удаётся.»

https://habr.com/ru/articles/791264/

А вы используете IAsyncEnumerable?

У меня сложилось впечатление, будто после релиза C# 8 про эту штуку все забыли, поэтому решил сегодня про неё вспомнить)

Этот тип данных решал задачу потребления и создания асинхронных потоков данных.

То есть, таких потоков, в которых данные получают или генерируют асинхронно.

Напомню, что если у нас есть некоторый метод:

static async IAsyncEnumerable<Data> GetData()
{
    // ...
}

То в таком случае, можно перебрать возвращаемое значение следующим образом:

await foreach (var item in GetData())
{
    // ...
}

Но что в таком случае будет наполнять тело метода GetData?

Обычно, асинхронные потоки удобны в том случае, когда данные представлены в виде набора батчей, но нам необходимо эмулировать целостность потока.

То есть, всё сразу предъявить мы не можем, но способны заявить об этой возможности.

Например, есть многостраничный список с фиксированным количеством элементов на одной странице.

Тогда, внутри метода GetData будет скачиваться одна страница и разворачиваться в плоский поток до тех пор, пока есть следующая страница:

static async IAsyncEnumerable<Data> GetData()
{
    var page = 1;
    while (page <= 10)
    {
        var items = await Fetch(page);
        foreach (var item in items)
            yield return item;
        page++;
    }
}

В вашей практике встречается потребность в IAsyncEnumerable?

Статические анонимные функции

Оказывается, в C# 9 лямбды получили серьёзное обновление!

Штука настолько малоизвестная, что меня даже ни разу не спрашивали про неё на собесах!

Допустим, у вас есть следующий код с замыканием:

int y = 1;
Func<int, int> lambda = x => x + y;

Захват переменной y и всего внешнего окружения вызовет ненужные аллокации.

С помощью ключевого слова static можно запретить подобные ситуации.

Тогда, обновлённый код не скомпилируется:

int y = 1;
Func<int, int> lambda = static x => x + y;

Однако, если очень нужно иметь возможность использовать y, но при этом сохранять эффективность кода, то переменную просто надо сделать константой:

const int y = 1;
Func<int, int> lambda = static x => x + y;

Кирилл сделал хорошее дополнение к последнему посту на своём канале @csharp_gepard

Бенчмарк показал, что производительность не меняется при добавлении static к делегату.

В целом ожидаемо и вполне логично, так как это compile guard

SSRS - зло?

Дорогие разработчики, рекомендую вам не соглашаться на любую разработку, связанную с отчётами.

Особенно, отчётами SSRS.

Разбираться, тестировать, отлаживать, ловить ошибки интерпретатора Basic и многое другое - это просто кошмар...

Если вы мне не верите, то ещё в 2015 году собрали 100 причин ненависти:

https://timwise.blogspot.com/2015/08/100-reasons-i-hate-ssrs.html

Напишите в комментариях своё отношение к SSRS

Польза IT за его пределами

У каждого специалиста в своей области есть позитивная профдеформация.

Некоторые ритуалы, которые возникли "на работе" и перешли в обычную жизнь, улучшив её.

Например, спортсмены в среднем более волевые, целеустремлённые и толерантные к неудачам люди.

Коммерческая разработка и процессы в продуктовых компаниях подарили мне системность подхода.

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

Каждый пост описывается как задача и декомпозируется до источников с референсами.

Благодаря такому отношению, мои телега и хабр расписаны минимум на полгода вперёд.

Скорее всего, этот пост вы прочитаете спустя месяц после его написания.

Так что программирование полезно не только своей зарплатой!