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

S>[кэп]
S>Помимо "запилить фичу" её неплохо бы покрыть тестами, документацией, поддержкой в IDE, убедиться, что она не поломает существующий код и т.д. и т.п. Это придётся делать вне зависимости от крутости фичи, ресурсы ограничены — приходится решать, что делать в первую очередь. Собственно, этим нормальный продукт и отличается от сделанного по принципу "потому что могу".
S>[/кэп]

Да, да. Именно этим они покрывают свои блоги. Там еще много подобной пурги.

S>Только плиз, давайте не будем холиварить на тему "А вот в ХХХ это добавляется за 0.1 сек, значит все кто не используют ХХХ — дураки и идиоты со синдромом блаба". И так чуть ли не полветки оффтопа.

Тут и холиварить не чего. Они долго жевали сопли, а теперь вот клепают Рослин, чтобы сократить объем блогов на тему "что нам помешало реализовать вот эту мелкую фичу".

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

VD>Да, да. Именно этим они покрывают свои блоги. Там еще много подобной пурги.
Ну блин. Ровно с той же аргументацией можно опустить любой язык:
1. Всё что говорят ваши оппоненты — пурга, язык отстой.
2. GOTO 1.

Ок, поставьте себя на место разработчиков шарпа. Первый релиз, одновременно с языком пишется весь BCL, winforms, asp.net, справка, средства для студии, учебники и курсы. Вообще не ясно, выстрелит ли язык, на всякий пожарный часть средств перекинута на васик/j#/mc++.

По срокам вы не успеваете добавить даже необходимые вещи типа генериков. Начальство требует релиз к сроку, т.к. маркетинг трубит про суперCOM++++ начиная с 99 года. Товарищи, которые только пощупали язык, обзывают явой в профиль и ругают за ненужные foreach, свойства, тормоза на топовых гигагерцовых процессорах и даже за enum-ы.

Ну как, будете добавлять именованные индексаторы?

VD>Тут и холиварить не чего. Они долго жевали сопли, а теперь вот клепают Рослин, чтобы сократить объем блогов на тему "что нам помешало реализовать вот эту мелкую фичу".
Тот же вопрос. К какому из релизов надо было выбросить все фичи и вместо этого 4 года пилить рослин?

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

S>Ну блин. Ровно с той же аргументацией можно опустить любой язык:
S>1. Всё что говорят ваши оппоненты — пурга, язык отстой.

Было бы можно, если бы в этом языке не было бы указанных фич. А я знаю минимум два языка в которых имеется 90% предложенных фич.

S>Ок, поставьте себя на место разработчиков шарпа. Первый релиз, одновременно с языком пишется весь BCL, winforms, asp.net, справка, средства для студии, учебники и курсы. Вообще не ясно, выстрелит ли язык, на всякий пожарный часть средств перекинута на васик/j#/mc++.

Первая версия языка была копией Явы к которой добавили такие вещи как: foreach, делегаты, события и goto. И делали ее неизвестное количество лет.

S>По срокам вы не успеваете добавить даже необходимые вещи типа генериков.

По срокам дженерики были разработаны одним человеком — Доном Саймоном — примерно за год. Это при том, что он добавлял их в компилятор написанный на С++. Они были доступны еще когда C# ходил в бэтах. Все изменения внесенные в дженерики в МС только ухудшили исходный дизайн. За возможность использовать параметр типа у внешнего типа вообще нужно было руки отрезать.

S>Начальство требует релиз к сроку, т.к. маркетинг трубит про суперCOM++++ начиная с 99 года. Товарищи, которые только пощупали язык, обзывают явой в профиль и ругают за ненужные foreach, свойства, тормоза на топовых гигагерцовых процессорах и даже за enum-ы.

Релиз C# был в 2002 году. Пилили его до этого несколько лет. Пилили не с нуля, а меняли Яву. Сегодня 2013 год. Прошло 11 лет.

Все предложенные для C# фичи были в Nemerle где-то в 2005 году. Nemerle в конце 2003 года.

S>Ну как, будете добавлять именованные индексаторы?

У меня они есть, так как я пишу на Nemerle. Причем есть уже около 7 лет. У тех кто пишет на VB они есть уже 11 лет.

VD>>Тут и холиварить не чего. Они долго жевали сопли, а теперь вот клепают Рослин, чтобы сократить объем блогов на тему "что нам помешало реализовать вот эту мелкую фичу".
S>Тот же вопрос. К какому из релизов надо было выбросить все фичи и вместо этого 4 года пилить рослин?

К первому, ваш КО. Тогда можно было бы съэкономить лет 5 на писание блогов.

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

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

S>Если не ёрничать — возможность использовать стейтменты как выражения — вполне удобна. Но для шарпа она принесёт заведомо больше минусов, чем плюсов.

Обоснуй, плиз, выделенное.

S>На этом предлагаю закругляться — у меня аргументы закончились, еси продолжать, будем только по кругу ходить.

Как-то странно закругляться на самом интересном. Только до конкретики дошли...

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

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

S>>Ну блин. Ровно с той же аргументацией можно опустить любой язык:
S>>1. Всё что говорят ваши оппоненты — пурга, язык отстой.
VD>Было бы можно, если бы в этом языке не было бы указанных фич. А я знаю минимум два языка в которых имеется 90% предложенных фич.
Ну, один — это точно N, второй, подозреваю — VB, так?

N офигенен, без вопросов. Но это язык для энтузиастов. Для попадания в мейнстрим и в типовой энтерпрайз-софт нужно приложить огромное количество усилий по популяризации и поддержке.
Только один пример (без обид, я ни в коем случае не хочу опустить N. В большинстве некоммерческих проектов всё гораздо хуже ). Проблема разных версий dll в немерле всплыла уже после релиза

Автор: _NN_
Дата: 06.02.13

. Для мейнстрима — это однозначный фейл, каким крутым не был бы язык.

Да, у МС больше ресурсов (мягко говоря ), но они тоже небесконечны. Так что если выбирать между "фича A, без которой могут обойтись 80% пользователей" и "фича B без которой нас пошлют лесом 80% пользователей" — мой выбор очевиден. Тем более, что против фичи A есть серьёзный довод: именованные индексаторы не входят в CLS.
Если включить их в CLS — такие вещи надо будет добавить во все прочие языки под .NET.
Если не включать — какая-то часть API дотнета будет использовать вместо индексеров методы collection.get_Items(index)/collection.set_Items(index)

Повторюсь: в мейнстриме всё не так просто, как кажется

VD>Первая версия языка была копией Явы к которой добавили такие вещи как: foreach, делегаты, события и goto. И делали ее неизвестное количество лет.
Угу. Напомнить, сколько по каждому из этих моментов было холиваров? Один только "Где мои указатели?!!! Я не хочу писать на бейсике!!!" всплывал раз 10 в месяц. ФП в то время вообще воспринималось как "это такой лисп? Что-то рассказывали, да", а на пике моды были ява и ООП.

VD>По срокам дженерики были разработаны одним человеком — Доном Саймоном — примерно за год. Это при том, что он добавлял их в компилятор написанный на С++. Они были доступны еще когда C# ходил в бэтах. Все изменения внесенные в дженерики в МС только ухудшили исходный дизайн.
Разработать и внедрить в продакшн — несколько разные вещи. Сам дизайн фичи — это хорошо если 10% затрат. Посмотрите, сколько усилий надо всего-то для добавления одного метода в API: тынц. Не, можно просто написать и выпустить, но тогда ровно столько же усилий уйдут на поддержку совместимостей со старыми версиями. Напомню, для мейнстрима даже 1% пользователей — это очень большие цифры. Если ничего не путаю, ещё в 2005м назывались цифры порядка 5 млн разработчиков (это не шарп, это все пользователи VS).

VD>За возможность использовать параметр типа у внешнего типа вообще нужно было руки отрезать.
Ок, как без этого шарить List<SomeObject> или Func<Foo,Bar> между разными сборками? Или под "использовать параметр типа у внешнего типа" подразумевается что-то другое?

S>>Тот же вопрос. К какому из релизов надо было выбросить все фичи и вместо этого 4 года пилить рослин?
VD>К первому, ваш КО. Тогда можно было бы съэкономить лет 5 на писание блогов.
Не вариант. Никто не даст вам занять команду специалистов на 4 года (минимум) без релизов и гарантированного выхлопа.

Саммари: задним числом всё кажется элементарным. На деле это слегка не так.

На этом у меня с аргументами всё, если не убедил — сдаюсь

P.S.
S>>Если не ёрничать — возможность использовать стейтменты как выражения — вполне удобна. Но для шарпа она принесёт заведомо больше минусов, чем плюсов.
VD>Обоснуй, плиз, выделенное.
Написал выше по ветке.

Минусы: в шарпе нет иммутабельных переменных, следовательно statement as expression будет неизбежно провоцировать побочные эффекты в выражении. Помимо того, у нас появляется два равноправных способа написать один и тот же код, причём разница между ними — исключительно в религиозных предпочтениях.

Плюсы: отпал один довод в холиварах на тему "чего нет в шарпе".

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

S>Минусы: в шарпе нет иммутабельных переменных, следовательно statement as expression будет неизбежно провоцировать побочные эффекты в выражении.

Каким образом C# уберегает от них сейчас и чем тут могут помочь иммутабельные переменные? Кстати, их введение очень дешево и совершенно не создает проблем обратной совместимости.

Да, и какие проблемы от побочных эффектов в выражении в императивном языке? Он специально проектируется для удобства создания побочных эффектов.

S>Помимо того, у нас появляется два равноправных способа написать один и тот же код, причём разница между ними — исключительно в религиозных предпочтениях.

Не понимаю проблемы. Это вроде такого?

if (a)
  if (b)
    DoSomething();
// vs
if (a && b)
  DoSomething();
// vs
var condition = a && b;
if (condition)
  DoSomething();

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

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

S>Ну, один — это точно N, второй, подозреваю — VB, так?

Второй Скала. Но в VB тоже пару фич есть, что нет в Шарпе.

S>N офигенен, без вопросов. Но это язык для энтузиастов. Для попадания в мейнстрим и в типовой энтерпрайз-софт нужно приложить огромное количество усилий по популяризации и поддержке.

Дык какие вопросы? Речь же идет о добавлении фич в Шарп. Фич давно проверенных на практике в других языках. Популяризацию шарпа уже произвели. Новые фичи только повысят ее.

S>Только один пример (без обид, я ни в коем случае не хочу опустить N. В большинстве некоммерческих проектов всё гораздо хуже ). Проблема разных версий dll в немерле всплыла уже после релиза

Автор: _NN_
Дата: 06.02.13

. Для мейнстрима — это однозначный фейл, каким крутым не был бы язык.

Хороший пример. Только это пример не из Немерла, а из .Net. В C# ее не видно просто потому что большая часть библиотек идет в составе фрэймворка. А ситуация когда есть две библиотеки созданные разными авторами и ссылающиеся на разные версии третьей библиотеки встречается крайне редко. Но ситуация таки встречается. Так что если это фэйл, то это фэйл МС.

S>Да, у МС больше ресурсов (мягко говоря ), но они тоже небесконечны.

Видимо именно по этому они тратят свои ресурсы попусту ведя разработку шарпа и дотнета на очень низкоуровневых языках вроде С++ и очень экстенсивными методами. Рослин, вот начали пилить через 10 лет после создания шарпа. И то боятся и осторожничают. А надо было сделать его в самом начале, а силы бросить на оптимизацию работы дотнета.

S>Так что если выбирать между "фича A, без которой могут обойтись 80% пользователей" и "фича B без которой нас пошлют лесом 80% пользователей" — мой выбор очевиден.

80%, очевидно, не видят дальше своего носа и ни послать не могут, ни требовать ничего не будут. Вот кто требовал появления ЛИНК-а? Хомячки хотели, в лучшем случае, Хибернэйт от МС. А тут такое.

S> Тем более, что против фичи A есть серьёзный довод: именованные индексаторы не входят в CLS.

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

S> Если включить их в CLS — такие вещи надо будет добавить во все прочие языки под .NET.

Все прочие — это БВ? Так там они уже есть. А в МС++ и индексаторов то нет. Так что с него не убудит.

Короче, это все бестолковые оправдания.

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

Меж тем МС героически пилит отдельный компилятор на С++ и еще языковый сервис на том же С++, которые на 80% повторяет компилятор.

Несколько лет назад, когда в МС еще не вилась работа над Рослином, нам (как сейчас про индексеры) объяснял, что совместить языковый сервис и компилятор невозможно. Им говорили — помилуйте, вот же Немерл у которого это именно так. Но им было по фигу. Они строчили блоги в которых убедительно (для тех кто не в теме) "доказывали" бесполезность совмещения компилятора и языкового сервиса.

Настали новые времена. В МС поменяли мнение и теперь даже не вспоминают, что несли чушь.

Так же будет и по остальным вопросам.

S> Если не включать — какая-то часть API дотнета будет использовать вместо индексеров методы collection.get_Items(index)/collection.set_Items(index)

Ах ты божеж мой?! Какая печалька! А сейчас что не та? Как на МС++ вызвать индексаторы?

S>Повторюсь: в мейнстриме всё не так просто, как кажется

Читайте меньше советских газет перед едой блогов.

VD>>Первая версия языка была копией Явы к которой добавили такие вещи как: foreach, делегаты, события и goto. И делали ее неизвестное количество лет.
S>Угу. Напомнить, сколько по каждому из этих моментов было холиваров?

Напомнить. Я помню только дин. Про то какие делегаты кривые.

S>Один только "Где мои указатели?!!!

Они то как раз и были в Шарп добавлены. В оригинале (Яве) их не было.

S>Я не хочу писать на бейсике!!!" всплывал раз 10 в месяц. ФП в то время вообще воспринималось как "это такой лисп? Что-то рассказывали, да", а на пике моды были ява и ООП.

Сегодня вот ситуация в корне другая. Люди спрашивают "где мой паттерн-матчинг и АлгТД?", а им в ответ пишут блоги в ктоторых объясняют почему их не будет.

VD>>По срокам дженерики были разработаны одним человеком — Доном Саймоном — примерно за год. Это при том, что он добавлял их в компилятор написанный на С++. Они были доступны еще когда C# ходил в бэтах. Все изменения внесенные в дженерики в МС только ухудшили исходный дизайн.
S>Разработать и внедрить в продакшн — несколько разные вещи.

Да, да. Заработать в сто раз сложнее. Этот процесс не распараллелить. А Дон не только придумал дизайн, но и реализовал его. В МС оставлось подправить баги и языковый сервис. Если бы сервис и компилятор имел общую кодовую базу, то второе и делать не надо было бы.

S>Сам дизайн фичи — это хорошо если 10% затрат.

Трепач находка для шпиенов. (с) мой отец

S>Посмотрите, сколько усилий надо всего-то для добавления одного метода в API: тынц.

Это плагиат. В оригинале было так:

— Степан! У гостя карета сломалась.
— Вижу, барин. Ось полетела. И спицы менять надо.
— За сколько сделаешь?
— За день сделаю.
— А за два?
— Ну… За… Сделаем и за два.
— А за пять дней?
— Ну, ежели постараться — можно и за пять.
— А за десять?
— Ну, барин, ты задачи ставишь! За десять дён одному не справиться, тут помощник нужен — хомо сапиенс!
— Бери помощников, но чтобы не раньше!

(с) Формула любви

S>Не, можно просто написать и выпустить, но тогда ровно столько же усилий уйдут на поддержку совместимостей со старыми версиями.

С дуру можно и...

VD>>За возможность использовать параметр типа у внешнего типа вообще нужно было руки отрезать.
S>Ок, как без этого шарить List<SomeObject> или Func<Foo,Bar> между разными сборками? Или под "использовать параметр типа у внешнего типа" подразумевается что-то другое?

Имеется в виду:

class A<T>
{
  class B
  {
    T x; // здесь доступен параметр типа внешнего типа
  }
}

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

S>>>Тот же вопрос. К какому из релизов надо было выбросить все фичи и вместо этого 4 года пилить рослин?
VD>>К первому, ваш КО. Тогда можно было бы съэкономить лет 5 на писание блогов.
S>Не вариант. Никто не даст вам занять команду специалистов на 4 года (минимум) без релизов и гарантированного выхлопа.

Ты явно не подумал прежде чем это сказал. Они они все равно написали отдельный компилятор и отдельный языковый севрис. Но сделали это на более низкоуровневом языке и в двое большими силами.

S>На этом у меня с аргументами всё, если не убедил — сдаюсь

Да нет у тебя аргументов. Ты защищаешь заведомо проигрышную позицию.

Реальные аргументы (которые не высказываклись) были следующими:
1. В МС не было нужного числа программистов пишущих на Шарпе/Яве.
2. У дотнета плохо с производительностью.
3. В МС не дальновидные ПМ-ы.

Но кто же в таких проблемах признается то? Вот и несут в блогах разную пургу.

S>P.S.
S>>>Если не ёрничать — возможность использовать стейтменты как выражения — вполне удобна. Но для шарпа она принесёт заведомо больше минусов, чем плюсов.
VD>>Обоснуй, плиз, выделенное.
S>Написал выше по ветке.

Не заметил.

S>Минусы: в шарпе нет иммутабельных переменных,

1. За чем дело стало?
2. В Шаре есть неизменяемые переменные: переменные из foreach, using, let и поля с модификатором readonly неизменяемы.

S>следовательно statement as expression будет неизбежно провоцировать побочные эффекты в выражении.

Да, да. А в экспрешонах проблем нет:

Foo(a = ++b)

И в Nemerle/F#/Scala тоже побочные эффекты где угодно могут быть. Это ни разу не проблема.

S>Помимо того, у нас появляется два равноправных способа написать один и тот же код, причём разница между ними — исключительно в религиозных предпочтениях.

У нас и без этого выше крыши возможностей написать одно и тоже разными способами. Напрмер, черз Линк и фиклами (решарпер даже одно в другое конвертирует в автомате). Это не помешало ввести тот же Линк.

S>Плюсы: отпал один довод в холиварах на тему "чего нет в шарпе".

Тогда не надо было свой язык делать. Реализовали бы Яву и жили бы счастливо.

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

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

T>>Что ты понимаешь под "хотя фичей из Немерла" ? Я вот хочу фичей которые увидел в других языках еще до рождения Немерла. Да и как то полистал список фич, все они появились когда Немерла еще не было

VD>Я имею в виду, что все желаемое они давно могли бы получить проинсталировав на машину один msi.

Это вобщем враньё или от недомыслия. Первый вопрос у менеджера — насколько сложно искать специалистов. Заходит к HR — они делают круглые глаза и вопрос отпадает само собой. Второй вопрос — сможет ли новичек в программировании поднять код на этом языке. Показывают новичку PM , не говоря про макры, новичек делает круглые глаза и вопрос снова отпадет. Третий вопрос — насколько качественный инструменты. Четвертый — насколько стабильный релиз. После ответа на эти вопросы можно начинать думать про инсталятор. А у тебя на инсталяторе все только начинается.

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

T>>Что ты понимаешь под "хотя фичей из Немерла" ? Я вот хочу фичей которые увидел в других языках еще до рождения Немерла. Да и как то полистал список фич, все они появились когда Немерла еще не было

VD>Я имею в виду, что все желаемое они давно могли бы получить проинсталировав на машину один msi.

Вот берем в качестве примера BLT, который ИТ фиксил шоб всунуть его в тот язык, который умеет Немерле но является якобы С#.
Ты предложил переписать часть кода, которая не работала, на Немерле. ИТ похоже идея не сильно понравилась.

Примерно так же будет и в энтерпрайзе. В маленькую команду можно всунуть все что хочешь.

А чуть больше — всё, приехали, C# и без вопросов.

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

VD>>>За возможность использовать параметр типа у внешнего типа вообще нужно было руки отрезать.
S>>Ок, как без этого шарить List<SomeObject> или Func<Foo,Bar> между разными сборками? Или под "использовать параметр типа у внешнего типа" подразумевается что-то другое?

VD>Имеется в виду:
VD>

VD>class A<T>
VD>{
VD>  class B
VD>  {
VD>    T x; // здесь доступен параметр типа внешнего типа
VD>  }
VD>}
VD>

а что тут не так?
VD>Учитывая, что типы часто используют для сокрытия областей видимости
что вы имеете в виду?
VD> это приводит к неочевидным проблемам.
каким?
VD>А уж сокрытие параметров типов это вообще смешно.
можно подробнее?

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

U>Сабж.

Для этого придется сделать совершенно другой язык. В рамках существующего шарпа это невозможно.

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

VD>И вообще, писать компилятор языке нужно исключительно на этом самом языке.

Новый компилятор шарпа написан на шарпе, причем на данный момент он компилирует сам себя.

AVK>Для этого придется сделать совершенно другой язык. В рамках существующего шарпа это невозможно.

это делается через зависимые типы, и это вполне можно сделать в шарпе

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

AVK>>Для этого придется сделать совершенно другой язык. В рамках существующего шарпа это невозможно.

DG>это делается через зависимые типы, и это вполне можно сделать в шарпе
а как быть с полями структур? их надо чем-то инициализировать по умолчанию.

DG>>это делается через зависимые типы, и это вполне можно сделать в шарпе
C>а как быть с полями структур? их надо чем-то инициализировать по умолчанию.

Неинициализированная структура введена в .net для совместимости со всякой хренью. В C# вполне можно обойтись без этого, и выдавать ошибку, если делается попытка создать неинициализированную структуру.


Основной затык может быть с созданием массива структур. Штука нужная, но не хватает синтаксиса для инициализации всех элементов одним видом конструктора.

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


DG>>>это делается через зависимые типы, и это вполне можно сделать в шарпе
C>>а как быть с полями структур? их надо чем-то инициализировать по умолчанию.

DG>Неинициализированная структура введена в .net для совместимости со всякой хренью. В C# вполне можно обойтись без этого, и выдавать ошибку, если делается попытка создать неинициализированную структуру.
а что делать с обратной совместимостью?


DG>Основной затык может быть с созданием массива структур. Штука нужная, но не хватает синтаксиса для инициализации всех элементов одним видом конструктора.
придется сделать этот синтаксис обязательным, а что делать с обратной совместимостью?

DG>>Неинициализированная структура введена в .net для совместимости со всякой хренью. В C# вполне можно обойтись без этого, и выдавать ошибку, если делается попытка создать неинициализированную структуру.
C>а что делать с обратной совместимостью?

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

В целом это очень похоже на то, как в .net была добавлена covariance contravariance семантика.

DG>>Основной затык может быть с созданием массива структур. Штука нужная, но не хватает синтаксиса для инициализации всех элементов одним видом конструктора.
C>придется сделать этот синтаксис обязательным, а что делать с обратной совместимостью?

Обязателен он только для типов, для которых объявлено, что они не могут быть null, соответственно, проблем с совместимостью не много.

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

VD>>И вообще, писать компилятор языке нужно исключительно на этом самом языке.

AVK>Новый компилятор шарпа написан на шарпе, причем на данный момент он компилирует сам себя.

Я в курсе. Вот только нужно было сделать это 10 лет тому назад.

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


DG>>>Неинициализированная структура введена в .net для совместимости со всякой хренью. В C# вполне можно обойтись без этого, и выдавать ошибку, если делается попытка создать неинициализированную структуру.
C>>а что делать с обратной совместимостью?

DG>Поведение старых типов останется таким же, как и было,
т.е. в старом коде ошибка выдаватся не будет?
DG>а вот стандартную либу желательно перегрузить, чтобы она одновременно могла работать и со строками, которыми могуть быть null, и которые не могут быть null, тоже самое и с коллекциями.
стандартную библиотеку придется продублировать. к старой версии дописать такую же, но с новыми типами.
DG>В целом это очень похоже на то, как в .net была добавлена covariance contravariance семантика.
не вижу аналогий.

DG>>>Основной затык может быть с созданием массива структур. Штука нужная, но не хватает синтаксиса для инициализации всех элементов одним видом конструктора.
C>>придется сделать этот синтаксис обязательным, а что делать с обратной совместимостью?
DG>Обязателен он только для типов, для которых объявлено, что они не могут быть null, соответственно, проблем с совместимостью не много.
т.е. прощай контекстно свободная грамматика? (т.е. она конечно уже давно не контекстно свободная)