Здравствуйте, IT, Вы писали:


IT>Прделагаю под двумя катами запрятать совсем севсем подсказку для совсем совсем ленивых.

А тут уже подсказывать нечего. Народ вообще разленился

default(ImmutableArray<T>) бросает исключения при попытке обращения к почти любому member-у. Если обращение идёт напрямую, то бросается NullReferenceException, что я расцениваю как тончайший троллинг со стороны авторов структуры. Но это ещё полбеды.

При обращении к ImmutableArray через интерфейсы бросается InvalidOperationException, которое, разумеется, никто не ожидает и не перехватывает. Результаты (из того, что дошло до конечных пользователей):
Failed to launch visual studio 2017,
(ASP.Net, VS 2015)design time host build fails with ImmutableArrayT error,
Can't sign in with Visual Studio 2017 RC
etc.

В общем народу понравилось, и теперь custom default struct constructors пропихивают в шарп. Верните Хейлсберга.

Здравствуйте, SergeyT., Вы писали:

ST>Да, это сильно.

S>>Я подробней распишу чуть пожже, как народ раскачается и нормально ответит.

С "раскачается" не вышло, так что расписал

Автор: Sinix
Дата: 01.03.17

.

Здравствуйте, Sinix, Вы писали:

S>В общем народу понравилось, и теперь custom default struct constructors пропихивают в шарп. Верните Хейлсберга.

Нет. Сначала пропихните в шарп ПМ, а потом уже возвращайте кого хотите.

Здравствуйте, IT, Вы писали:

S>>Верните Хейлсберга.
IT>Нет. Сначала проаихните в шарп ПМ, а потом уже возвращайте кого хотите.

Некогда ж. Зато у нас есть тюплы, 8 синтаксисов для задекларить свойство и local-функции

Хотя не, вру. Ещё throw as expression есть. Который как бы часть match expression, но последнего пока нет. Не выбрасывать же
И вишенкой на торте: соблюдая традиции, codegen переехал в c# 9. Вроде бы переехал. И вроде бы в 9.


Как ни крути, при Хейлсберге такого эпичного раздолбайства не было.

Здравствуйте, Sinix, Вы писали:

Совсем подсказка должна заключаться в том, как вот такое скомпилировать.

using System;
using System.Collections.Generic;

#IF COMPILE_ME_IF_U_CAN
using System.Collections.Immutable;
#ENDIF

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion> — Пробовал.
<TargetFrameworkVersion>v4.6.1</TargetFrameworkVersion> — тоже.

Уже потом можно будет будет шарады с этой штукой разглядывать.

Здравствуйте, Философ, Вы писали:


Ф>Совсем подсказка должна заключаться в том, как вот такое скомпилировать.

	внезапно

Здравствуйте, Sinix, Вы писали:

S>Как ни крути, при Хейлсберге такого эпичного раздолбайства не было.
Зато есть прекрасный TypeScript

Здравствуйте, _NN_, Вы писали:

S>>Как ни крути, при Хейлсберге такого эпичного раздолбайства не было.
_NN>Зато есть прекрасный TypeScript
Это тонкий троллинг? Язык хорошо разрекламирован, хороший доя этого класса синтаксис и абсолютно тупой компилятор и полное отсутствие модульности. Вы как хотите — но писать на goigle-closure — намного приятнее когда у вас кода под мегабайт и больше и есть привычка разделять тип на файл, что является общепринятой практикой. Инклуды через коменты — не являются заменой. При этом реализация с выкидыванием простейшего мертвого кода буквально на уровне файлов — элементарна. Так что нет. Это всё ещё игрушка.

Здравствуйте, fddima, Вы писали:

F>Здравствуйте, _NN_, Вы писали:

S>>>Как ни крути, при Хейлсберге такого эпичного раздолбайства не было.
_NN>>Зато есть прекрасный TypeScript
F> Это тонкий троллинг? Язык хорошо разрекламирован, хороший доя этого класса синтаксис и абсолютно тупой компилятор и полное отсутствие модульности. Вы как хотите — но писать на goigle-closure — намного приятнее когда у вас кода под мегабайт и больше и есть привычка разделять тип на файл, что является общепринятой практикой. Инклуды через коменты — не являются заменой. При этом реализация с выкидыванием простейшего мертвого кода буквально на уровне файлов — элементарна. Так что нет. Это всё ещё игрушка.
Это уже в прошлом.
Есть import как полагается: https://www.typescriptlang.org/docs/handbook/modules.html#import

Здравствуйте, fddima, Вы писали:

F> Инклуды через коменты — не являются заменой. При этом реализация с выкидыванием простейшего мертвого кода буквально на уровне файлов — элементарна.

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

Здравствуйте, fddima, Вы писали:

F>Здравствуйте, _NN_, Вы писали:

S>>>Как ни крути, при Хейлсберге такого эпичного раздолбайства не было.
_NN>>Зато есть прекрасный TypeScript
F> Это тонкий троллинг? Язык хорошо разрекламирован, хороший доя этого класса синтаксис и абсолютно тупой компилятор и полное отсутствие модульности. Вы как хотите — но писать на goigle-closure — намного приятнее когда у вас кода под мегабайт и больше и есть привычка разделять тип на файл, что является общепринятой практикой. Инклуды через коменты — не являются заменой. При этом реализация с выкидыванием простейшего мертвого кода буквально на уровне файлов — элементарна. Так что нет. Это всё ещё игрушка.

Ты видно давно не брал в руки TS. При этом нужно учитывать, что при компиляции может использоваться ES6 со всеми вкусностями.
Ты видно и Angular 2 в руки не брал. Googl как раз много делает для его развития именно в связке с TypeScript.

https://angular-2-training-book.rangle.io/handout/modules/introduction.html

Здравствуйте, Sinix, Вы писали:

S>default(ImmutableArray<T>) бросает исключения при попытке обращения к почти любому member-у. Если обращение идёт напрямую, то бросается NullReferenceException, что я расцениваю как тончайший троллинг со стороны авторов структуры.

Так это правильно, это же smart-pointer, считай — легковесная обертка.
Т.е. значение этой обертки — это значение сохранённой внутри ссылки.
Задача такой обертки — максимально дешево транслировать вызовы на объект по ссылке унутре.
Семантика такой обертки в точности равна семантике сохранённого ссылочного типа, за исключением намеренно привносимых вещей — например, отсутствуют операции изменения элементов массива.


S>В общем народу понравилось, и теперь custom default struct constructors пропихивают в шарп. Верните Хейлсберга.

Это надо было пропихнуть одновременно с выходом генериков в 2005-м.
Дефолтная инициализация структур — это дыра в системе типов.
Не всякая дефолтная структура валидна. ImmutableArray — отличный пример.

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

Здравствуйте, vdimas, Вы писали:

V>Т.е. значение этой обертки — это значение сохранённой внутри ссылки.
V>Задача такой обертки — максимально дешево транслировать вызовы на объект по ссылке унутре.

Чисто технически — да. С точки зрения разработчика под дотнет (и тем более — энтерпрайз разработчика) добавление такого типа в public api без подробной документации и без рослиновского аналайзера — признак серьёзнейших проблем в команде. Потому что либо код последовательно прошёл прототипирование, design review, тесты и внутренний догфудинг, либо команда работает без всего этого. Оба варианта хуже.

Не, может для кого-то добавление в библиотеку типа, использование которого приводит к крэшам студии, невозможности подтвердить лицензию студии, ошибкам в дизайнерах XAML и asp.net, исключениям в компиляторе, крэше рефакторинга в VB, багам в xunit, падению тестов newtonsoft.json и тыды и тыпы выглядит приемлемо, не знаю

Для меня — это залёт.


V>Это надо было пропихнуть одновременно с выходом генериков в 2005-м.
Ну, т.е. одного типа с неотлавливаемым исключением в произвольный момент времени мало, да?



V>Дефолтная инициализация структур — это дыра в системе типов.
V>Не всякая дефолтная структура валидна. ImmutableArray — отличный пример.
Матчасть читать надо

DO ensure that a state where all instance data is set to zero, false, or null (as appropriate) is valid.
This prevents accidental creation of invalid instances when an array of the structs is created. For example, the following struct is incorrectly designed. The parameterized constructor is meant to ensure a valid state, but the constructor is not executed when an array of the struct is created and so the instance field value gets initialized to 0, which is not a valid value for this type.

(с) FDG book.
Т.е. если официальные гадлайны требуют трактовать default(ImmutableArray) как пустой массив, — тем хуже для гадлайнов.


V>Более того, было бы неплохо довести эту фичу до конца и дать возможность запретить дефолтный конструктор для структур, точно так же как для классов. Это всё для целей consistency, ес-но.
Не вопрос. Благодаря этой чудесной политике "совместимость? не, не слышал" .net core сегодня полумёртв как платформа. Ибо переход на него с взрослого дотнета ничем принципиально не отличается от перехода на любую другую платформу. Хотя не, вру. С остальными платформами рисков меньше.

Здравствуйте, Sinix, Вы писали:
S>Не вопрос. Благодаря этой чудесной политике "совместимость? не, не слышал" .net core сегодня полумёртв как платформа. Ибо переход на него с взрослого дотнета ничем принципиально не отличается от перехода на любую другую платформу. Хотя не, вру. С остальными платформами рисков меньше.
То есть NetStandard 2 не изменит твоего мнения?

Да есть проблемы переноса, но новый проект лучше делать на .Net Core, так как он развивается в отличие от ...

Здравствуйте, Serginio1, Вы писали:

S> То есть NetStandard 2 не изменит твоего мнения?

А моё мнение тут при чём? Оно как раз в противоположную сторону повёрнуто, т.к. я хоть и краем глаза, но за этим праздником жизни поглядываю.

А вот народ, который принимает решения — он куда как менее оптимистичен, причём не в одной и не в двух конторах. Как я понял из обсуждений, логика такая: ошибки в новых проектах, сырость инструментария и прочее — фиг с ним, рабочий момент. А вот принципиально неверные решения, которые идут вразрез с прошлым опытом, но продавливаются до последнего и разруливаются только постфактум, после выкатки даже не бет — релиза — это ой. Ну а если такое повторяются раз за разом, причём по нескольким проектам внутри одной компании — только любим помним скорбим. Желательно заранее, чтобы потом в очереди не толкаться.

С моей точки зрения всё не так мрачно, но будем посмотреть.

Здравствуйте, vdimas, Вы писали:

S>>В общем народу понравилось, и теперь custom default struct constructors пропихивают в шарп. Верните Хейлсберга.

V>Дефолтная инициализация структур — это дыра в системе типов.
V>Это надо было пропихнуть...

Обсуждаемые безаргументные конструкторы — это не про дефолтную инициализацию структур. Семантика `default(S)` не поменяется — это зануление. Речь про `new S()`.

V>...одновременно с выходом генериков в 2005-м.

Безаргументные конструкторы изначально были в CLI. И даже в превью C# побывали в течение небольшого времени в 2015 году, насколько я помню. Но в релизе C# 6.0 их выпилили из-за нюансов совместимости.

Здравствуйте, Sinix, Вы писали:

S>Для меня — это залёт.

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

Представь, что вы обычные ссылочные типы перестанете проверять на null? ))

Но меня тут ДРУГОЙ залёт рассмешил.
Он в самой системе типов C# (недавно обсуждали с коллегой samius).

Фишка вот в чём:
— если брать тру-генерик-алгоритмы с ограничениями, то с такой структурой будет происходить работа без боксинга:

void MyAlgorithm<T>(T collection) where T : IEnumerable<T>
{...}

Но тогда невозможна будет ad hoc перегрузка сигнатуры:

void MyAlgorithm<T>(T collection) where T : IQueryable<T>
{...}

Для сравнения, в Хаскель такая перегрузка сигнатур возможна и является основным ср-вом построения иерархий типов в программах на ём.

В дотнете же приходится делать так:

void MyAlgorithm<T>(IEnumerable<T> collection)  
{...}

void MyAlgorithm<T>(IQueryable<T> collection) 
{...}

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

Я бы тут предложил для ValueType ввести статический метод:

class SmartPtr {
...
  public static implicit operator Box<SmartPtr>(SmartPtr value) {
    if(value.IsEmpty)
      return null;

    return new Box<SmartPtr>(this);
  }
}

Некий тип Box всё-равно присутствует унутре VM, можно этот тип как-то отобразить наружу.
Ведь именно тип Box реализует (в смысле подставляет) виртуальные методы value-типа.


V>>Это надо было пропихнуть одновременно с выходом генериков в 2005-м.
S>Ну, т.е. одного типа с неотлавливаемым исключением в произвольный момент времени мало, да?

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


V>>Дефолтная инициализация структур — это дыра в системе типов.
V>>Не всякая дефолтная структура валидна. ImmutableArray — отличный пример.
S>Матчасть читать надо

Ой, начинается... ))
Тут как раз НЕ проблема сделать так, чтобы для value-полей объектов или для элементов массива вызывались конструкторы структур по-умолчанию.

Т.е., если мы определили некую структуру:

struct ImmutableArray<T> {
  public SmartPointer() {
    _array = Array.Empty<T>();  
  }

private:
  T[] _array;
}

То ничего страшного от вызова дефолтных конструкторов в полях объектов или в массивах не случится. На этом сидит С++ и неплохо себя чувствует.
Совсем другое дело, когда дефолтный конструктор запрещен, фича из С++:

struct NotNull<T> where T : class {
  public NotNull(T obj) {
    if(obj == null) throw ...;
    _obj = obj;
  }

  NotNull() = delete;    // или объявлен в приватной секции

private:
  T _obj;
}

Тогда создать массив таких структур можно будет только с подачей дефолтного значения (как в oCaml), типа так:

using MyTypeRef = NotNull<MyType>;

var defaultValue = new MyTypeRef(MyType::DummyObj);
MyTypeRef[] values = new MyTypeRef[42](defaultValue);

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


S>Т.е. если официальные гадлайны требуют трактовать default(ImmutableArray) как пустой массив, — тем хуже для гадлайнов.

Гадлайны писаны под имеющуюся систему типов, но эта система типов почти с каждым релизом дорабатывается.


V>>Более того, было бы неплохо довести эту фичу до конца и дать возможность запретить дефолтный конструктор для структур, точно так же как для классов. Это всё для целей consistency, ес-но.
S>Не вопрос. Благодаря этой чудесной политике "совместимость? не, не слышал"

Похоже, ты недочитал.
Не запретить, а дать возможность запретить.
Т.е. речь идёт о неких новых типах.


S>.net core сегодня полумёртв как платформа. Ибо переход на него с взрослого дотнета ничем принципиально не отличается от перехода на любую другую платформу. Хотя не, вру. С остальными платформами рисков меньше.

Я тебя умоляю. Это не проблема программистов, это проблема популярности Win10/UWP на ноутах и девайсах.

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

Здравствуйте, vdimas, Вы писали:

S>>Для меня — это залёт.
V>Это из-за отсутствия практики оперирования умными указателями.

Блин, я уж не знаю как объяснить.

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

В очередной версии ты игноришь свои же рекомендации, которые соблюдались с полтора десятка лет и в public API добавляешь тип, который нельзя передавать и принимать в качестве аргумента без валидации в каждом из методов. Иначе рано или поздно приложение скрэшится с null ref exception. Понятно, что ни один вменяемый девелопер не будет перехватывать null ref где-то в теле метода, это изврат из серии on error resume next.

Ну, т.е. ты добавил в public API тип, который бросает неперехватываемые исключение.

И теперь начинается момент, который ты не слышишь: в ответ на "WTF, бро?" клиенты слышат не "ну упс, вот документация, вот аналайзер для рослина / правило решарпера/ещё что-нибудь, вот guidelines, не повторяйте наших ошибок". Неа, им начинают продавать отсутствие практики работы с смартпойтерами, рецепты лучших слоноводов и прочий набор баззвордов для буллшит бинго. Причём предыдущие n версий всё как-то работало без вышеперечисленного

Не, с технической стороны всё ок, но с точки зрения клиентов всё выглядит так, как я написал выше.
При этом клиенты знают, что похожее решение уже пробовали (code contracts пытались протолкнуть моду на неперехватываемые исключения) и это решение (в числе прочих) привело к смерти продукта. Т.е. негативный опыт игнорится.

Также клиенты припоминают, что такие же косяки с полным игнором фидбэка за последние пару лет встречались с полдесятка раз, причём по всем командам, от рослина с EF и до corefx. В связи с чем возникает резонный вопрос: а не пора ли раскидать яйца по другим корзинкам?

Вот в этом реальная проблема, а не в мелочах типа

V>Но тогда невозможна будет ad hoc перегрузка сигнатуры:

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



V>Все базовые либы построены именно по такому паттерну, и в этом месте возникает дополнительный боксинг такой обертки.
Кэп: к моменту, когда тебя в плане производительности будет волновать лишний боксинг, все IEnumerable и Queryable будут давно выпилены из hotpath. Реальные проблемы искать и чинить надо, а не те, про которые народ на форуме пишет



V>Внутри MyAlgorithm происходит проверка на null, ОК, но боксированная структура не будет null-ом никогда.
V>Вот причина засады.
V>Она фундаментальна, её не перепрыгнешь.

Неа. Причина засады в том, что кто-то "догадался" сделать структуру IEnumerable/IQueryable. Всё остальное — уже следствие. Ну, как сломать палец, а затем жаловаться что стенки слишком твёрдые — тыкать в них больно.


S>>Ну, т.е. одного типа с неотлавливаемым исключением в произвольный момент времени мало, да?
V>Наоборот, возможность строгой инициализации исключит вероятность таких ошибок даже в случае дефолтного боксинга.
Вот без обид, но не надо рассказывать, как сделать язык 1 на знаниях языка 2. Потому что твоё требование ломает пустые массивы, десериализацию, orm, маппинг, интероп, dynamic, expression trees, code emit и ещё кучу вещей в фреймворке. И заодно блочит рельно perf-critical вещи типа Span<T>.

Ну, т.е. или троллинг, или полное незнание внутреннего устройства.
В любом из вариантов спор на тему "что не так в фреймворке" не получится


S>>.net core сегодня полумёртв как платформа. Ибо переход на него с взрослого дотнета ничем принципиально не отличается от перехода на любую другую платформу. Хотя не, вру. С остальными платформами рисков меньше.
V>Я тебя умоляю. Это не проблема программистов, это проблема популярности Win10/UWP на ноутах и девайсах.

Ну, т.е. оно само так получилось, а не как результат кучи мегафакапов, в том числе и политики в отношении разработчиков, да?
По факту ситуация такая: консумерский десктоп мёртв, для "я хочу продавать продукт по цене чашки кофе" есть андроид и яблоко и там всё пока неплохо с xamarin/unity. Вопрос про веб, энтерпрайз и облако.

Здравствуйте, Sinix, Вы писали:

S>>>Для меня — это залёт.
V>>Это из-за отсутствия практики оперирования умными указателями.
S>Блин, я уж не знаю как объяснить.

А и не надо. Это ж букварь.
А у меня стёб над ним и дележ другими практиками.

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

Тип ImmutableArray — тому подтверждение.
Лично мне тут весело, потому что аналог ImutableArray у меня появился сразу же во всех дотнетных проектах, как только появились генерики.
И не только у меня.
И плевали все на эти лузерские гайды.
Ведь не только я плевал, я же не в вакууме живу — я видел просто тонны примеров, когда вменяемые разработчики закрывали глаза и пилили value-обертки над ref-классами.
Потому что смириться с чудовищной стоимостью абстракций непросто.
Тут или отказываться от абстракций, или отказываться от дотнета, или закрывать глаза на гайды.
ИМХО, выбор тут слишком очевиден, чтобы пытаться даже рыпаться в сторону защиты неких гайдов.

Помнишь я тут как-то показывал увеличение в 2.5 раза на дотнете с пол-тыка за счет уменьшения косвенности?
В реальных приложухах за счёт этого до 3-4-х раз идёт улучшение эффективности, когда вообще всё перерабатывается через такой же трюк.
А какой срач вдруг разыгрался, помнишь?
Причем, придирались как раз ко всякой совершенно не принципиальной фигне.
Показательно. Потому что им шашечки, а мне ехать.
И для меня это надёжнейшая лакмусовая бумажка для отделения карьеронацеленных очковтирателей от полезных людей.
Потому что гайды по первым практикам писались саботажниками-диверсантами, которых давно уже погнали ссаными тряпками из MS, слава богу.
Всё, забудь про них.
Липперт принёс плохую карму в MS, отмываться надо будет еще о-о-очень долго.
Вот что бывает, когда средней руки инженер превращается в маньяка-карьериста.

И пофик на "кол-во вовлечённых разработчиков", реально.
Интересовать может лишь полезный имеющийся код и понимание приоритета следующих для решения задач, а не половые трудности тяжелых на подъем разработчиков.

Я лишь показал, какие изменения можно будет вводить в дотнет для обеспечения идиом безопасных легковесных оберток, чтобы не задеть уже имеющийся код. И я недоумеваю — почему топовые дотнетные специалисты этого форума САМИ не предположили ровно эти же изменения как вариант решения вполне конкретной инженерной задачи? Что с вами не так-то?

Разве сам не увидел, что тут вина разработчиков ImmutableArray лишь в том, что они "побежали впереди паровоза"?
Почему мне надо озвучивать вслух те банальности, что им тоже не шашечки, а ехать надо было.
Просто у них вполне определённых навыков еще не было, вот и спотыкаются пока:

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

Ну ничего, дотнет не сразу строился когда-то.
А сейчас ему (дотнету) кровь из носу надо перестаиваться или он исчезнет на твоё удивление слишком быстро.
Так шта, тебе тут выбирать — или расширять свои практики, или попрощаться с любимым инструментом.
Выбор очевиден, ИМХО.
И твои заламывания рук — это, таки —

А ошибки исправят. MS обычно оперативно правит ошибки, тут у них есть чему поучиться.
Например, можно везде в linq и прочих методах-расширениях ввести альтернативные сигнатуры сугубо для аргумента ImmutableArray<T>, где проверить его на пустоту ПРАВИЛЬНО. Затем достаточно будет лишь пересобрать имеющиеся исходники и ву а ля? NullReferenceException будет вылетать ровно там, где его первый раз подают, а не где пытаются использовать спустя километры тиков процессора. ))

Здравствуйте, Qbit86, Вы писали:

V>>Дефолтная инициализация структур — это дыра в системе типов.
Q>Обсуждаемые безаргументные конструкторы — это не про дефолтную инициализацию структур.

Не надо меня поправлять, я выразился ровно так, как и собирался.


Q>Семантика `default(S)` не поменяется — это зануление. Речь про `new S()`.

Это и есть дыра. Потому что var s = default(S); или return default(S);
Дырой я называю такую ситуацию, когда обнулённое значение структуры невалидно.

Но желательно иметь такую систему типов, которая позволит конструировать объекты лишь в валидном состоянии, верно?


Q>Безаргументные конструкторы изначально были в CLI. И даже в превью C# побывали в течение небольшого времени в 2015 году, насколько я помню. Но в релизе C# 6.0 их выпилили из-за нюансов совместимости.

Из-за того, что уже 2015-й год, а не 2005-й.
Надо было раньше...
Но они к этому всё-равно придут.
Просто релиз поджимал, некоторые фичи к релизу не успевали.
Не успели к этому, сделают к одному из последующих.

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

Там ведь слишком много зависимых моментов тянутся влед за всеми этими вещами.
Например, в С++ std::vector<T> может предвыделить память, а инициализировать значениями позже.
Аналогичный List<T> в дотнете под собой имеет вполне типизированный array в кач-ве буфера, элементы которого надо как-то инициализировать не позже, а прям сразу. Вот тебе достойная задачка для пошевелить шестерёнками, размять мозжечок, такскаать. ))