Возможные фичи C# 5

Никто толком не знает что будет в следующей версии языка C#. Даже люди в C# Insiders (я в их числе) понятия не имеют, что там Microsoft придумает. Тем не менее, в сети есть очень много действительно хороших предложений, несколько из которых я решил представить ниже. Надеюсь получится хорошая дискуссия.

Замена для IEnumerable<T> — тут идея в том, что мы слишком много букв пишем, и что лучше, как это сделано в Boo, заменить IEnumerable одной буквой, чтобы можно были писать T* или T~. К сожалению, звездочка вполне может запутать тех, кто знает что такое указатель, так что придется поискать другой оператор.

Синтакcический сахар для dependency property. Идея простая – реализация DP на данный момент невменяема, т.е. выглядит как “код с известного полуострова” и мейнтейнить такие нагромождения не хочется. Уж лучше написать следующее:

public Message
{
  get; set;
  default { return "No message"; }
  assign { Console.WriteLine("Just changed message!"); }
}

И так далее. Соответственно, реализации INotifyPropertyChanged, IDataErrorInfo, IEditableObject и так далее тоже хочется получать автоматически, а не через нагромождения, как это делается сейчас.

NonNullable типы, то есть типы которые не могут быть null в принципе. Помечаем тип как T! (дуальная аналогия T?, что соответствует Nullable<T>) и всё! Некоторым правда этого мало – они хотят чтобы все типы были ! by default.

yield из анонимных функций – думаю тут все понятно. От себя добавлю, что было бы круто если бы можно было использовать var вместо полного описания прототипа. Например:

var z = (int [] x => { foreach (var y in x.Where(x % 2 == 0)) yield return y; }

Также была бы полезна поддержка yield foreach, т.е. возможность делать рекурсивный yield без двойного обхода. Вот что имеется ввиду:

public IEnumerable<Person> OldPeople(this Person person)
{
  if (person.Age > 80) yield return person;
  // instead of this
  foreach (var result in OldPeople(person.Children))
    foreach (var p in result)
      return p;
  // we write this
  foreach yield OldPeople(person.Children);
}

Sequence-инициализация, чтобы например 1..10 производило то же самое, что Enumerable.Range(1, 10).

Правильная инициализация кортежей. Сейчас метод может вернуть два значения в Tuple<T,U>, но получать их нужно через .Item1 и .Item2. Это нечитабельно, и лучше делать вот так:

(sex,death) = GetMeaningOf(life);

Хотя лучше всего наверное использовать struct-тип для возврата, т.к. иначе подсказки о том что возвращается можно получить только из документации.

Как альтернатива – возможность возвращать анонимные именованые типы, примерно вот так:

public static new { T X, T Y } Vector2<T>(this T k)
{
    return new { X = k, Y = k };
}

Оператор цепочной проверки на null. Например, если один из элементов person.Address.PostCode является null, мы получим исключение, а проверять их все—лень. Поэтому хочется получить оператор а-ля ?. чтобы написал вот так person?.Address?.PostCode мы получили null если любой из элементов null.

Extension properties — у нас уже есть методы, а если еще будут свойства (как в F#), то легче будет делать примеси. Это некий аналог multiple inheritance который, насколько я понимаю, есть например в Scala.

Скрытая ленивость — иначе говоря, обертка вокруг Lazy<T> которая позволить переменной быть ленивой без всяких .Value и так далее. Например:

class C
{
  yield int Z;
  public C()
  {
    Z = SomeLazyComputation(); // only done when asked
  }
}

Приватные поля для свойств — еще одна идея как инкапсулировать поля когда объект не является POCO:

class C
{
  public int N
  {
    int n = 0;
    get { return n; }
    set { if (value != n) {
      n = value;
      NotifyPropertyChanged("n");
    } }
  }
}

Если у вас есть еще какие-то идеи насчет новой версии языка – пишите!

150 responses to “Возможные фичи C# 5”

  1. Собственно большая часть предложенного уже давно реализовано в Nemerle. Так что не ясно, что сидеть и ждать милости от “природы” когда их можно получить уже сейчас, здесь и совершенно бесплатно.

    Вот, например, использование макроса упрощающего работу с dependency property:
    http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/Nemerle.WPF/Test/Main.n
    а вот его реализация:
    http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/Nemerle.WPF/Nemerle.WPF/DependencyProperty.n

    Единственное чего нет и трудно реализовать в рамках Nemerle – это NonNullable-типы, так как для качественного результата такую фичу нужно поддерживать на уровне рантайма.

  2. Ухты. Не знал о Lazy. У меня давно есть свой InVal.Lazy для подобных целей.

    Smth?.Address?.PostCode – это круто и очень желаемо

    Также желанно
    1) создавать собственные (нечитабельные ;) ) операторы |> ||> [->] – на вкус пользователя
    2) разрешить define с параметром
    Две эти фичи могут быть источниками ошибок – (но иногда без них очень плохо) – поэтому пусть исспольнование их нужно включать в Properties наподобие unsafe.

    .Net Framework фичи:
    1) Управлять, кто первый среди WeakReference уйдет

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

    1. А что плохого в том, что предлагаемые фичи заимствуются из других языков?

      Заимствование возможностей – это нормальный процесс. Есть только 2-3 языка в которых фичи придуманы с нуля. В остальных – это развитие идей взятых из других языков.

      В том же C# нет ни одной новой идеи. Все заимствовано. Даже LINQ имеет прототип – Haskell DB.

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

  4. Вобщем, я так понял, все согласны с тем, что с C# надо завязывать, а то будет новый С++.
    А тем временем кто-нибудь разработает новый язык, который будет содержать все плюшки и даже больше. Правда, есть предположение, что лет через 5 и этого будет мало. И вот тогда мы снова встретимся где-нибудь в коментах =)

    1. Ну это еще не гарантия того, что его будут использовать. Посмотри например на Google Go.

      1. А что с Go?

        Это экспериментальный язык который только-только появился на свет. Его судьба пока неизвестна. Но то что за ним стоит мощная компания – Гугль – говорит о том, что язык может и выжить.

  5. Я не фанат ФП, хотел бы такого сахара:
    1. Нормальные Extension method (ref/out/static classes) + extension properties
    2. Сделать что-нибудь с замыканием в foreach
    3. var в полях
    4. yield return из анонимных функций
    5. constraint на отдельные функции и операторы

  6. скажу честно, что при создании крупных учетных систем самым главным являлось – удачное проектирование всей системы и модулей в частности. а именно, простыми словами:
    – модель абстрактного хранилища, отвязанного от конкретной реализации СУБД;
    – выделенный исполнитель бизнес-логики, отвязанный от отображения и конкретной реализации СУБД, с построением объектов и обвязыванием их поведением;
    – гибкая система генерации и кастомизации интерфейсов (вэб или окна, или даже консоль, не важно)
    И такие подробности, как всяческие фичи в языках – капля в море по затратности и рискам получения гибкой и масштабируемой системы. Что есть фичи, что нет, это ни чего не меняет. При грамотной организации всех видов работ, постоянном активно контроле и тестировании – ни каие фичи не нужны. Я это испытал уже более чем за 15 лет. Ну вот вообще ни как они не нужны и ни чем не помогают в вопросах достижения глобальных целей, как бы не ныли и не гундосили программисты.
    Более того скажу – чем больше фич, тем:
    – дольше работают программисты
    – больше зависимость от программиста
    – дороже они стоят
    – больше рисков от качества фич
    Я иногда удивляюсь, почему в России так много программируют, почему так часто переписывают системы, почему так много гениально талантливых программистов копаются в фичах…

    1. Это всё вообще не про то. Конечно для менеджера проекта важнее нормально налаженный цикл тестирования, чем сокращение для IEnumerable. Конечно, высокоуровневая архитектура тоже важна. Но это не тот уровень.

      Простой пример: можно сделать модель абстрактного хранилища без LINQ, но это дольше и дороже.

      В таинственное мнение, что при большем кол-ве фич программисты работают медленнее (в каких единицах? кто это вообще мерял?), я не верю.

      Вы думаете Майкрософт и другие компании, развивающие языки программирования, тратят на это деньги потому что они хотят чтобы проекты на этих языках делались медленнее и дороже? Да вовсе нет, наоборот они в первую очередь заинтересованы в том, чтобы их клиенты получали какую-то выгоду от использования их языков, иначе никто их не будет использовать.

    2. Более того, для автора этого поста и для многих комментаторов архитектура на том уровне, о котором вы говорите, это дело само собой разумеещееся.

      Конечно, можно нанять быстрых и дешёвых людей, не слушать что они там “ноют”, и сделать тесты и контроль за качеством кода (например, посадить архитектора делать code review). Видел таких заказчиков тоже. Но результат будет либо очень дорогим (архитектор проверил, сказал всё перереписать, и так много раз), либо с трудом поддерживаемым в будущем.

      1. Во первых, мелкосфт делает фишки, которые вас привлекают – это главное для них! Наивно предполагать, что это не основная их цель. Именно поэтому вы в последствии так много тратите времени на изучения, так часто обсуждаете проблемы, и так долго изворачиваетесь, чтобы используя предложенный инструмент сделать что-то серьезное. Не успев закончит обсуждение, “у вас в почте” новая реклама от мелкософт, о новых фичах в С# под названием “для ленивых”.
        Во вторых. То, что у вас так случалось “архитектор сказал все переписать” – это именно то, о чем я и говорю – некачественная организация работ, по большей части потому, что менеджеры проектов и архитекторы имеют очень высоко задранный нос, и торчат на таких форумах или вообще неизвестно где торчат. Контроль исполнения работ участниками должен быть очень активным. Программист должен получать задачи, которые он сможет решить не более чем за 1-2 часа, или результаты этапов работ можно было бы проверить с такой частотой. Архитектор – тот же инженер, что и программист, хотя его задачи не всегда можно разделить на этапы или с большей вероятностью оценить риски. Но его так же необходимо проверять и контролировать, чтобы было понятно, туда ли он движется. И надо бы проводить предпроектные исследования и тесты, чтобы снизить риски такого исхода – “архитектор сказал – все надо переписать”.
        Вы таки предлагаете сидеть копаться в фичах?

    3. Как по мне так программисты работают как раз меньше. Другое дело что если систему написали “крутаны” а на саппорт вы поставили “динозавров” которые боятся слова лямбда и не знают что такое метод расширения — то тогда вы возможно и заслужили такие проблемы.

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

      1. В чем-то я конечно с вами согласен. Но это не обязательно верно сажать на саппорт программистов. Все опять же зависит от компании.
        Если это научные исследования в, как вы сказали, “маленькая консалтинговая компания которая не разгребает авгиевы конюшни а занимается интересными, прогрессивными вещами”, то наверное наука ради науки – это полезно для будущих качественных скачков в этой области. Где-то так лет через 50. Но пока что видны мягкие и незначительные эволюционные поползновения на протяжении десятков лет. Я говорю с точки зрения полезности практиков, работающих в отрасли. И это понятно, область то новая – разработка алгоритмов и внедрение их в исполнительную систему – например, персональный компьютер. Пока ни чего особого в отличиях нет среди самых разноцветных языков и концепций в изложении задач исполнительной системе. А именно это определяет глобальные затраты и стимулирует цели. И разговоры о фичах по мне так – копание в песочнице. Я ни кого не заставлю иметь такое же мнение. Просто и мне, как кроме всего еще и практикующему программисту, вполне достаточно концептуальных новшеств в новых средах разработке.

  7. Стас Агарков Avatar
    Стас Агарков

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

  8. Некоторые фичи интересны, но пожайлуста – не надо из стройного и типизированного C# делать делфи-скриптообразное Г…! сенкс

    1. Вот отличное замечание! Я даже побоялся написать такое, потому, что предполагал, что на меня обрушится шквал Г… людей с таким менталитетом: “а я хАчу чтобА звездАчка писалась до АпиратАра, и чтобА мышАй меньшИ двигать”юю и ете же авторы дальше: “… потому что это это согласуется с современно модой в ИТ отрасли, особенно на ландшафтах интеграционных проектов и с активным развитием функционального программирования и идеологии префиксного изложения”.
      И побоялся потому, что автора забросали таки Г…ом, когда он отметил, что больше бы надо заниматься повышением качеств уже созданных фич, их большей интеграцией и развитием, чем замусориванием языка “элементами для лентяев”, попытался предложить улучшить возможности по дэбаггингу, трассировке и тестированию фич, и его опять обГ..нили…

      1. Да не нервничайте вы так! Этот топик сам по себе флеймовый, поэтому естественно что тут много людей и много мнений.

      2. ну таки плохо то, что мОлодежжжь впитывает не лучшие практики, не лучший подход к делу…
        это как осам халявный мед, или наркоманам халявные наркотики. только покажи – слетаются и маньячат “на тему”… а они составляют определенную часть отрасли, и они могут своими настроениями и пожеланиями повлиять на развитие других.. и так это может стать необратимым лавинообразным процессом расщепления :)))) (“не дай бог”)
        взять только некоторые новшества в C# 4, которые приводят к расхолаживанию и потере строгости языка… интересно, что было бы с математикой, если бы там вот такой бред творился.. но там с этим сложно, там всегда требуются доказательства и обоснования, там труд, а здесь – маркетинг, “заманилово” лентяев, затягивание в болото….

  9. Я пропустил или упоминания о итераторах не было? :)

  10. да… фичи, перефичи…
    вот бы всех этих айтишников заселить на отдельную территорию, где голые степи и леса, скинуть им строительных материалов в большом количестве и строительной техники, и сказать – что и когда построите, в том и тогда и будете жить!
    вот это будет РЖАЧКА!!!

    1. Не очень сравнение. Равно как строителям дать компы и поглядеть как они … Кстати, вы в новых домах квартиры видели :)

      Я вот только в одном согласен – не надо из C# делать этакий супер PHP с читабельностью RegExp. Причем у меня складывается ощущение что в жертву фичам приносится производительность.

      1. Извините, не совсем точно выразил мысль. Забыл добавить – “если бы программисты были строителями и строили дома…”
        Вот быстренько нашел то, что читал когда то.
        http://mshakurov.narod.ru/IT_Compatible.html
        Развлекитесь.

      2. Да я понял что про этот прикол речь :) Просто все равно – криво. А тут серьезный флейм :) :) :)

  11. Про сахар рассказали, а про самое главное, метапрограммирование – нет.

    1. А что там рассказывать? Сказали же “Компилятор как сервис”. Это значит, что вы сможете взять компилятор и делать с ним что захотите. :)

      А метапрограммирования, как и сахара не будет.

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

      В прочем, опять же не ясно что ждать мифического будущего когда можно уже здесь использовать метапрограммировние, но не в рамках C#.

      1. «Компилятор как сервис» и “метапрограммирования не будет” – взаимоисключающие явления.

      2. Да нет, пожалуйста, вот в Mono уже compiler-as-service, если можно так сказать. А метапрограммирование — совсем другого уровня штука, чем написать свой компилер/препроцессор.

        Есть ещё VS, есть ещё необходимость этот компилятор вручную поддерживать, etc.

      3. Если воображение очень сильное, то можно утверждать, что метапрограммирование было всгеда и есть сейчас, так как всегда моджно сгенерировать код в текстовый файл и скомпилировать этот файл.

        Тот же T4 есть, так что генерировать код не так уж и тяжело получается.

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

        “Компилятор как сервис” упростит возможность компиляции кода в рантайме, но тех возможностей что есть, скажем в Nemerle или Lisp-е он не даст. А без этого продуктивной работы небудет.

        В Nemerle и Lisp-е можно сварганить внутренний DSL и элегантно решить проблему. А вот компилятор-компонет (а именно это пока что подразумевается за красивым слоганом “Компилятор как сервис”) этой гибкости и легкости не даст.

        Даже если компилятор позволит вмешиватся в процесс компиляции (что очень сомнительно) – этого все равно мало, для разработки действительно мощьных решений, так как трудоемкость процесса расширения (без фичи вроде макросов) будет просто неподъемной.

  12. […] комментариев в блоге и вот, пожалуйста, флейм. Тема: "Возможные фичи C# 5". Чуть позже Майкла Хэр (Michael Hare) поделился своим […]

  13. Хорошая тема поднята!

  14. Инлайн инициализация автоматических свойств, подобно инициализации полей. Например:

    string Name { get; set; } = “Urrri”;

    string Name { get; set; value=”Urrri” }

  15. Extension properties

    про них писал Эрик Липперт, поечму от них отказались. ДАлеко не факт что снова решат вернуться

  16. а яб добавил кроме T! еще и T% значение задается только однажды и не может быть изменено.

    1. а readonly не то?

  17. Скорее к .NET чем к C#:
    1. INumeric interface for standard numeric types.
    struct UInt32: INumeric
    {

    }
    2. Discriminated unions:
    union MyUnion: Enum
    {
    case Enum.Red: RedClass;
    case Enum.Green: GreenClass;

    }
    3. Fixed size arrays
    byte[10] x;

  18. Только “Синтакcический сахар для dependency property” зацепило. Здорово будет конечно, если реализуют. Всё остальное ни о чем.

    1. > Только «Синтакcический сахар для dependency property» зацепило

      В C# их точно не появится. Негоже язык под одну библиотеку рсширять.
      А вот в Nemerle оно уже давно доступно в виде библиотеки:
      http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/Nemerle.WPF/Test/Main.n

      1. Будем надеятся что в С#5 появятся механизмы метапрограммирования и тогда проблема отпадет сама собой.

Leave a reply to Dmitri Cancel reply