Комментарии 21
Если массивы и так передаются по ссылке, какой практический смысл в спане для массива?
Вся соль в слайсах. Так можно передавать часть массива и работать в функции с ним, как цельным. Т.е. функции типа Func(byte[] buffer, int offset, int length) можно просто превратить в Func(Span<byte> buffer).
Ну и главное, что Span - это не только управляемый массив, за ним может быть и неуправляемая память. Соответственно тебе достаточно будет написать одну функцию с реализацией для Span, вместо отдельных реализаций для byte[] и byte*. Хотя реализация в таком случае обычно сводятся к unsafe с fixed массива, но со Span можно писать safe реализацию, что тоже плюсом.
Ну, можно сделать свою собственную структуру с этими полями, и передавать ее. И когда мне приходилось ограничиваться возможностями .NET Framework 4.5.2 (потому что в Windows Server 2012 R2 стоял именно он), в котором никаких Span не было, я именно так и делал для всяческих разборок (AKA parsing).
Но в наше время у Span есть преимущество: его библиотека времени выполнения вполне прилично поддерживает.
В дополнение к тому что выше - Span<T> позволяет работать со staсkalloc-массивами без использования unsafe кода.
В этом и смысл, чтобы не создавать новые объекты, а просто оперировать одним. Для строк сейчас много таких перегрузок.
Довольно поздно, но об этом как-то не упоминают, поэтому оставлю здесь так сказать "для будущих поколений".
Одна из критических особенностей Span заключается в обобщении коллекций, даже не оптимизации.
Можно написать метод T Sum (ReadOnlySpan<T> data) where T : INumber<T> и вызывать его для любой коллекции, представленной как последовательный блок памяти. Работает для T[], List<T>, IList<T>, ReadOnlyCollection<T> и даже T*
Без Span это бы требовало дубликации кода и огромная часть BCL написана именно так. Раньше им приходилось писать методы на C/C++ и дергать их с PInvoke. Конечно, это не что-то новое, просто теперь работать с этим несколько проще.
а discriminated unions когда-то появятся?
Есть уже несколько официальных предложений/обсуждений, выглядят они пока довольно неловко (можно тут порыться https://github.com/dotnet/csharplang/tree/main/proposals , некоторые уже в discarded, некоторые просто висят)
Когда коту делать нечего он яйца лижет.
Exhaustive switch,
Pattern matching,
Discriminated unions
Higher-kinded types (хотя бы через type providers и quotations)
Где вот это вот всё?
В другом языке. В этом - пали жертвой принципа YAGNI (хотя, какой-то pattern matching в C# все же притащили). B это правильно: не надо перегружать язык всем хорошим (и не очень), что только взбредет в голову или удастся подсмотреть у конкурентов. Язык IMHO должен оставаться концептуально целостным, чтобы быть обозримым. В частности, не надо тащить FP в C#, по крайней мере, пока компилятор не научится контролировать типы параметров-делегатов на отсутствие побочных эффектов.
История с PL/1 должна была этому научить, по крайней мере - тех кто ее застал.
в F#. Юзайте его)
Pattern matching появился еще в C# 7 и в следующих версиях усовершенствовался.
Нововведения C# 14 принесли ещё больше удобств и расширили возможности разработчика, хотя и без изменений жанра "синтаксический сахар" тоже не обошлось.
По-моему, все перечисленное в статье - оно именно в этом жанре. Всё это можно было сделать и раньше, только больше текста набирать пришлось бы.
И да, появление нвого синтаксического сахара читабельность, скорее, понижает - как минимум, до тех пор, пока он не станет привычным. А до того он будет постоянно вызывать вопросы, что это за хрень. А если как это сейчас принято, новую версию языка выпускать каждый год, то читабельность будет страдать регулярно.
ИМХО, большая часть читаема, даже если не знаешь о таких фичах. Тотже field или проверка на null сложно интрепитировать как-то иначе.
Я думаю, в типовом коде найдётся больше проблем, которые вызовут не только сложности с читаемостью, но и всякие разные позывы, чем новые конструкции языка. Не вижу трагедии, добавленные фичи в большинстве интуитивно понятны и без букваря. Проблема не в их чтении, а в их использовании, но этому способствуют IDE с подсказками и авто-рефакторингом.
Обзор нововведений в C# 14