Свеженькое (ну, относительно ) о _возможных_ добавлениях в c#7:
Non-nullable reference types (already working on them)
Non-nullary constructor constraints (require CLR support)
Support for INotifyPropertyChanged (too specific; metaprogramming?)
GPU and DirectX support (mostly library work; numeric constraints?)
Extension properties and static members (certainly interesting)
More code analysis (this is what Roslyn analyzers are for)
Extension methods in instance members (fair request, small)
Unmanaged constraint (requires CLR support)
Mulitple returns (working on it, via tuples)
ISupportInitialize (too specific; hooks on object initializers?)
Statement lambdas in expression trees (fair request, big feature!)
Language support for Lists, Dictionaries and Tuples (Fair; already working on tuples)
Don't instantiate C![] : it's elements would be null.
This seems like a draconian restriction — as long as you only ever read fields from the array that were previously written,
no-one would observe the default value. Many data structures wrapping arrays observe this discipline.
Всё обсуждение тоже советую почитать, там очень любопытный и подробный комментарий Мэтта Торвальдсена про "string == string!". Как всегда, некоторые вещи надо делать с самого начала...
Здравствуйте, Sinix, Вы писали:
S>Всё обсуждение тоже советую почитать, там очень любопытный и подробный комментарий Мэтта Торвальдсена про "string == string!".
Все Ок, только Мэдса зовут Мэдс Торгерсен (Mads Torgersen) =)
Здравствуйте, VladD2, Вы писали:
VD>Ух! Ну, хорошо, что не Ингеборга Дапкунайте (человек-скороговорка).
Да ну! Я общался с чуваком по имени Анандхариву Джхаранджья. Вот это — скороговорка.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Да ну! Я общался с чуваком по имени Анандхариву Джхаранджья. Вот это — скороговорка.
Да фиг с ним, с индусом. То как ты с Рихтером общался, не затмит ничто и останется на вечно! =)) И, что характерно, Мэдс принимал в этом диалоге посильное участие — если возвращаться к теме топика
Здравствуйте, Sinix, Вы писали:
S>Что-то все забыли про сабж.
Интересно, никому не приходило в голову что Expression Bodied Functions and Properties хорошо бы дополнить возможностью использовать using statement в качестве expression? Да и само по себе using expression кажется весьма полезным на первый взгляд.
S>Интересно, никому не приходило в голову что Expression Bodied Functions and Properties хорошо бы дополнить возможностью использовать using statement в качестве expression? Да и само по себе using expression кажется весьма полезным на первый взгляд.
Что-то типа
using x = (string a) => int.Parse(a);
...
var b = x("123");
?
Не, нафиг-нафиг. Получится что-то типа текстовых макросов с, только ещё и живущих в рамках одного файла. Используйте методы, тем более что с инлайном простых выражений особых проблем нет.
S>using x = (string a) => int.Parse(a);
S>...
S>var b = x("123");
S>
S>?
S>Не, нафиг-нафиг. Получится что-то типа текстовых макросов с, только ещё и живущих в рамках одного файла. Используйте методы, тем более что с инлайном простых выражений особых проблем нет.
Речь про то, что return из using (var r = ...) { } делать можно, но сам он не является выражением, что препятствует написанию
public string GetSomething(string a) => using (var r = GetR(a)) { [return] r.DoSomething(); }
Здравствуйте, Sinix, Вы писали:
S>Всё обсуждение тоже советую почитать, там очень любопытный и подробный комментарий Мэтта Торвальдсена про "string == string!". Как всегда, некоторые вещи надо делать с самого начала...
А почему нельзя сделать новую версию компилятора и сломать совместимость со старыми граблями? В новом коде ставить какую-нибудь директиву, предписывающую компилировать по новым правилам.
Здравствуйте, samius, Вы писали:
S>Речь про то, что return из using (var r = ...) { } делать можно, но сам он не является выражением, что препятствует написанию
public string GetSomething(string a) => using (var r = GetR(a)) { [return] r.DoSomething(); }
Ну, т.е. нужно добавить новую фичу в язык, чтобы можно было не писать "{ ... }". Это при том, что и исходный лямбда-синтаксис без поддержки pure-методов тоже не очень нужен был.
Нафиг-нафиг. А то потом понадобится for/if expressions, затем semicolon operator, затем last statement as return и всё это потому, что девелопер хочет запихнуть в одно выражение всё тело метода.
Если совсем коротко:
1. не надо хороший язык превращать в PHP
2. у statement и expression есть чёткое разделение: последнее не приносит побочных эффектов, по крайней мере, не должно. Во времена раннего шарпа это кучу раз обсуждалось, в последнее время под наплывом начинающих разработчиков про это все основательно забыли
Ну и взгляд на это же дело из лагеря F#. Автор отмороженный на всю голову (в хорошем смысле) фанат функционального программирования, читать с осторожностью
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, samius, Вы писали:
S>Ну, т.е. нужно добавить новую фичу в язык, чтобы можно было не писать "{ ... }". Это при том, что и исходный лямбда-синтаксис без поддержки pure-методов тоже не очень нужен был. S>Нафиг-нафиг. А то потом понадобится for/if expressions, затем semicolon operator, затем last statement as return и всё это потому, что девелопер хочет запихнуть в одно выражение всё тело метода.
Мы ведь это обсуждаем как раз в контексте новой фичи, позволяющей не писать "{ ... }" для методов и свойств, записываемых одним выражением.
if-у есть замена ?:, а for expression это ИМХО перебор.
S>Если совсем коротко: S>1. не надо хороший язык превращать в PHP S>2. у statement и expression есть чёткое разделение: последнее не приносит побочных эффектов, по крайней мере, не должно. Во времена раннего шарпа это кучу раз обсуждалось, в последнее время под наплывом начинающих разработчиков про это все основательно забыли
Это не аргумент против using-expression, т.к. будучи обернутым в тело метода, using statement может (но вовсе не обязан) натворить побочных эффектов, и сойдет за варажение.
S>Конкретно для шарпа: S>http://blogs.msdn.com/b/ericlippert/archive/2009/05/18/foreach-vs-foreach.aspx S>http://stackoverflow.com/questions/19132/expression-versus-statement
Я знаю, чем отличается выражение от стейтмента
S>Ну и взгляд на это же дело из лагеря F#. Автор отмороженный на всю голову (в хорошем смысле) фанат функционального программирования, читать с осторожностью
Кстати, в F# try/catch, try/finally являются выражениями, а use keyword работает практически как let-binding. Да и методы могут объявляться без скобочек. F# уже PHP, или еще не дорос?
Здравствуйте, samius, Вы писали:
S>>Нафиг-нафиг. А то потом понадобится for/if expressions, затем semicolon operator, затем last statement as return и всё это потому, что девелопер хочет запихнуть в одно выражение всё тело метода. S>Мы ведь это обсуждаем как раз в контексте новой фичи, позволяющей не писать "{ ... }" для методов и свойств, записываемых одним выражением.
Ну а смысл пытаться запихнуть в одно выражение то, что в него не лезет?
Код пишут для того, чтоб его читали и поддерживали, а не чтобы LoC экономить.
Уже есть стандартные coding guidelines, которые в частности рекомендуют сразу использовать полную форму, например
if (SomeCondition)
{
DoSomething();
}
// вместоif (SomeCondition)
DoSomething();
Причин этому куча, самые простые: меньше дурацких ошибок, одинаковый стиль кода, при правках не надо впихивать/убирать скобки, они есть всегда.
Нет блин, хочется сначала понаступать на те же грабли, а затем добавлять coding guidelines уже для expression-ов
S>if-у есть замена ?:, а for expression это ИМХО перебор.
т.е. using — это не перебор? Как насчёт foreach/ifelse? Вложенные ifelse кстати лучше читаются, чем "?:".
+ надо помнить, что expression-ы могут использоваться везде, т.е. using внутри linq — уже легальная штука. Получаем правку expression trees, костыли ко всем linq-провайдерам и невозможность компиляции кода под младшие версии фреймворка. Зашибись исправленьице, да?
S>Это не аргумент против using-expression, т.к. будучи обернутым в тело метода, using statement может (но вовсе не обязан) натворить побочных эффектов, и сойдет за варажение.
Скажем так: есть хороший дизайн, который надо постараться чтобы использовать неправильно, а есть фиговый дизайн, который фиг используешь правильно, зато ошибки допускаются на раз-два.
Плохой — это не значит "намеренно сделан плохим", всё проще: дизайн ваял человек, который не знает/не заботится о _реальных_ сценариях использования.
Каждое "фигак-фигак и в продакшн" само по себе может и неплохо, но в итоге любой долгоживущий код превращается в маленький кошмар. Потому что человек А зафанател от ФП и прикрутил всё на выражениях, человек Б упростил всё до хелперов, человек C поверх этого написал оппа-оппа-интерн-стайл и всё это в конце уходит на поддержку к самым квалифицированным специалистам, потому что 1: срочно, 2: никто больше не разберётся
Не, можно утвердить стандарт кодирования, втащить код-ревью и просто не допускать неправильных сценариев, но это опять-таки работа на ровном месте, из разряда "лишь бы не как раньше".
К сожалению, чтобы прочувствовать всю прелесть решений "ты усложняешь, всё ж просто?" надо поработать над большим (т.е. в принципе не делается одной группой из 5-10 человек) долгоживущим (минимум 2-3 года продуктивной разработки) проектом. И вот когда три года твоей работы придётся или закопать из-за "всё-просто" решений или ценой усилий всей команды оставить свою часть в отличном состоянии — вот тогда к фигак-фигак нарабатывается очень здоровый скептицизм.
Да, вполне возможно я ошибаюсь и рано или поздно using expr в шарпе появится. Но и тогда я могу быть уверен, что перед добавлением c# team рассмотрела все косяки и corner cases (типа возни с expression trees) и или документировала их, или предусмотрела какое-то решение на будущее. Т.е. с меня эта головная боль снята
В общем, это всё тот же вопрос о последствиях расширении языка неспециалистами. Кто пробовал — больше что-то не хочет.
Так вот, using в expression-ах — это плохой дизайн. Именно потому, что использование юзиногв обычно предполагает внесение неявных побочных эффектов.
Если уж припёрло — такие вещи надо всё-таки явно документировать, вытащив в отдельный метод, а не смешивать pure и impure-часть.
S>>Ну и взгляд на это же дело из лагеря F#. Автор отмороженный на всю голову (в хорошем смысле) фанат функционального программирования, читать с осторожностью S>Кстати, в F# try/catch, try/finally являются выражениями, а use keyword работает практически как let-binding. Да и методы могут объявляться без скобочек. F# уже PHP, или еще не дорос?
Не дорос. Потому что f# с самого начала был FP-языком, большинство стейтментов в нём — pure, mutable декларируется явно. Поэтому "всё есть выражение" на F# ложится очень классно.
На изначально олдскульно-императивный шарп ФП-заморочки напротив, налезают с трудом. Потому что реальный код и реальный API не заточены под принятые в ФП сценарии использования. Следовательно, или новые добавления будут использоваться в мизерных количествах в весьма специфичном коде, или будут использоваться во вред.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, samius, Вы писали:
S>>Мы ведь это обсуждаем как раз в контексте новой фичи, позволяющей не писать "{ ... }" для методов и свойств, записываемых одним выражением. S>Ну а смысл пытаться запихнуть в одно выражение то, что в него не лезет?
В F# залезло S>Код пишут для того, чтоб его читали и поддерживали, а не чтобы LoC экономить. S>Уже есть стандартные coding guidelines, которые в частности рекомендуют сразу использовать полную форму, например S>
S> if (SomeCondition)
S> {
S> DoSomething();
S> }
S>// вместо
S> if (SomeCondition)
S> DoSomething();
S>
S>Причин этому куча, самые простые: меньше дурацких ошибок, одинаковый стиль кода, при правках не надо впихивать/убирать скобки, они есть всегда.
S>Нет блин, хочется сначала понаступать на те же грабли, а затем добавлять coding guidelines уже для expression-ов
Expression Bodied Functions уже наступили на все грабли. И не я их предложил. То есть скобки и грабли с гайдлайнами не аргумент в случае Expression Bodied Functions, но почему-то аргумент в случае using...
S>>if-у есть замена ?:, а for expression это ИМХО перебор. S>т.е. using — это не перебор? Как насчёт foreach/ifelse? Вложенные ifelse кстати лучше читаются, чем "?:".
S>+ надо помнить, что expression-ы могут использоваться везде, т.е. using внутри linq — уже легальная штука. Получаем правку expression trees, костыли ко всем linq-провайдерам и невозможность компиляции кода под младшие версии фреймворка. Зашибись исправленьице, да?
Ненене, Дэвид Блейн! Не все что можно засунуть легально в expression проглотят linq-провайдеры и это не приводит к костылям. Поэтому не аргумент.
S>>Это не аргумент против using-expression, т.к. будучи обернутым в тело метода, using statement может (но вовсе не обязан) натворить побочных эффектов, и сойдет за варажение. S>Скажем так: есть хороший дизайн, который надо постараться чтобы использовать неправильно, а есть фиговый дизайн, который фиг используешь правильно, зато ошибки допускаются на раз-два. S>Плохой — это не значит "намеренно сделан плохим", всё проще: дизайн ваял человек, который не знает/не заботится о _реальных_ сценариях использования.
S>Каждое "фигак-фигак и в продакшн" само по себе может и неплохо, но в итоге любой долгоживущий код превращается в маленький кошмар. Потому что человек А зафанател от ФП и прикрутил всё на выражениях, человек Б упростил всё до хелперов, человек C поверх этого написал оппа-оппа-интерн-стайл и всё это в конце уходит на поддержку к самым квалифицированным специалистам, потому что 1: срочно, 2: никто больше не разберётся
S>Не, можно утвердить стандарт кодирования, втащить код-ревью и просто не допускать неправильных сценариев, но это опять-таки работа на ровном месте, из разряда "лишь бы не как раньше".
Expression Bodied Functions потребуют утверждения стандартов кодирования. На том же ровном месте.
S>К сожалению, чтобы прочувствовать всю прелесть решений "ты усложняешь, всё ж просто?" надо поработать над большим (т.е. в принципе не делается одной группой из 5-10 человек) долгоживущим (минимум 2-3 года продуктивной разработки) проектом. И вот когда три года твоей работы придётся или закопать из-за "всё-просто" решений или ценой усилий всей команды оставить свою часть в отличном состоянии — вот тогда к фигак-фигак нарабатывается очень здоровый скептицизм.
Работал на проектах и побольше. И мне не очевидно, почему такие проекты придется закапывать из-за using-expression.
S>Да, вполне возможно я ошибаюсь и рано или поздно using expr в шарпе появится. Но и тогда я могу быть уверен, что перед добавлением c# team рассмотрела все косяки и corner cases (типа возни с expression trees) и или документировала их, или предусмотрела какое-то решение на будущее. Т.е. с меня эта головная боль снята
Вопрос был изначально не в том, что бы на кого-то повесить головную боль, а в том, не приходило ли кому в голову, не обсуждалось ли? И только лишь.
S>В общем, это всё тот же вопрос о последствиях расширении языка неспециалистами. Кто пробовал — больше что-то не хочет.
S>Так вот, using в expression-ах — это плохой дизайн. Именно потому, что использование юзиногв обычно предполагает внесение неявных побочных эффектов. S>Если уж припёрло — такие вещи надо всё-таки явно документировать, вытащив в отдельный метод, а не смешивать pure и impure-часть.
pure и impure отлично смешиваются и без using-ов. да и никто не озаботился явной документацией pure и impure.
S>>Кстати, в F# try/catch, try/finally являются выражениями, а use keyword работает практически как let-binding. Да и методы могут объявляться без скобочек. F# уже PHP, или еще не дорос? S>Не дорос. Потому что f# с самого начала был FP-языком, большинство стейтментов в нём — pure, mutable декларируется явно. Поэтому "всё есть выражение" на F# ложится очень классно.
S>На изначально олдскульно-императивный шарп ФП-заморочки напротив, налезают с трудом. Потому что реальный код и реальный API не заточены под принятые в ФП сценарии использования. Следовательно, или новые добавления будут использоваться в мизерных количествах в весьма специфичном коде, или будут использоваться во вред.
F# как раз заточен на работу в том же рантайме и том же фреймворке, что и C#. Кейворд use в частности заточен на работу с IDisposable, сценарии использования которого в точности совпадают со сценариями его использования на C#.
Здравствуйте, Sinix, Вы писали:
S> Mulitple returns (working on it, via tuples)
А чего за этим зайцем-то погнались? Кому-то сахара не хватает? Вот серьёзно, кто-то может привести пример реального кода, который станет "гораздо более лучше" с множественным возвратом?
Т.е. вдруг я отстал от жизни и что-то реально упускаю?
Здравствуйте, Mr.Delphist, Вы писали:
S>> Mulitple returns (working on it, via tuples) MD>Вот серьёзно, кто-то может привести пример реального кода, который станет "гораздо более лучше" с множественным возвратом?
Для существующих областей применения шарпа — нет его практически. Лучше бы declaration expressions для
if (int.TryParse(input, out var x))
{
// use x
}
сделали. Пока про них ничего не слышно, но это и понятно — для c#7 только-только предложения отбираются.
Но во-первых, бардак с тюплами/анонимными типами и рекордами надо бы свести к одному знаменателю. В связи с добавлением паттерн-матчинга это особенно актуально. Иначе получится один синтаксис для ПМ, другой для разбора/сбора тюплов, третий — для рекордов и тд.
И во вторых, шарп пытаются сделать более дружественным к скриптовому стилю в связи с свежим asp.next и попытками привлечь линуксоводов и мобильных разработчиков. Хорошо это или плохо — это уже как кому нравится.
S>>Нет блин, хочется сначала понаступать на те же грабли, а затем добавлять coding guidelines уже для expression-ов S>Expression Bodied Functions уже наступили на все грабли. И не я их предложил. То есть скобки и грабли с гайдлайнами не аргумент в случае Expression Bodied Functions, но почему-то аргумент в случае using...
Потому что exp bodied хороши для существующих выражений. А вот попытка добавить impure-выражения испортит и expression bodied тоже. Потому что смысл в них окончательно потеряется.
S>>+ надо помнить, что expression-ы могут использоваться везде, т.е. using внутри linq — уже легальная штука. Получаем правку expression trees, костыли ко всем linq-провайдерам и невозможность компиляции кода под младшие версии фреймворка. Зашибись исправленьице, да? S>Ненене, Дэвид Блейн! Не все что можно засунуть легально в expression проглотят linq-провайдеры и это не приводит к костылям. Поэтому не аргумент.
А, ну т.е. ешё хуже решение. Теперь у нас есть выражения для expression-tree и выражения, которые не подходят для expression-tree и всё это ещё и различается для разных версий фреймворка. Как человек, писавший хоть и наколенный, но linq-провайдер — поверьте, там и без этого геммороя хватает
S>>Не, можно утвердить стандарт кодирования, втащить код-ревью и просто не допускать неправильных сценариев, но это опять-таки работа на ровном месте, из разряда "лишь бы не как раньше". S>Expression Bodied Functions потребуют утверждения стандартов кодирования. На том же ровном месте.
На сегодня нет. Т.к. ничего сложнее одного "?:" или linq-запроса туда не влазит. Т.е. правил достаточно тех же, что для любой одиночной строчки кода.
S>>К сожалению, чтобы прочувствовать всю прелесть решений "ты усложняешь, всё ж просто?" надо поработать над большим (т.е. в принципе не делается одной группой из 5-10 человек) долгоживущим (минимум 2-3 года продуктивной разработки) проектом. И вот когда три года твоей работы придётся или закопать из-за "всё-просто" решений или ценой усилий всей команды оставить свою часть в отличном состоянии — вот тогда к фигак-фигак нарабатывается очень здоровый скептицизм. S>Работал на проектах и побольше. И мне не очевидно, почему такие проекты придется закапывать из-за using-expression.
Не только из-за него. Когда у тебя на руках регулярно оказывается код, который надо поддерживать, но
1. Единственное, что с ним можно сделать — это сжечь и засыпать солью.
2. Код даже трогать нельзя, т.к. он стоил несколько человеколет разработки, а код, который от него зависит — стоит эдак на порядок больше.
3. Исправление нужно прямсейчасиписецкаксрочно
решения из разряда "лишь бы не как в гадлайнах" начинаешь очень не любить
S>Вопрос был изначально не в том, что бы на кого-то повесить головную боль, а в том, не приходило ли кому в голову, не обсуждалось ли? И только лишь.
Обсуждалось конечно, ссылки на обсужденее более общей проблемы я в первом ответе и привёл. Вы там ещё написали "Я знаю, чем отличается выражение от стейтмента"
S>pure и impure отлично смешиваются и без using-ов. да и никто не озаботился явной документацией pure и impure.
Тем не менее на сегодняшний момент в шарпе надо специально постараться, чтоб запихнуть impure-код в выражения.
S>F# как раз заточен на работу в том же рантайме и том же фреймворке, что и C#. Кейворд use в частности заточен на работу с IDisposable, сценарии использования которого в точности совпадают со сценариями его использования на C#.
Ну так и немерль и iron python заточены. Языками со своей концепцией и сценариями использования они от этого быть не перестали
В expression bodied methods уже можно запихнуть statement'ы, завернув их в immediately-invoked function expression. Я так понимаю, samius'у будет достаточно сахара, не нужны хитрые expression trees.
) о _возможных_ добавлениях в c#7:
Мы уже победили, просто это еще не так заметно...
