Почему в качестве statement может быть только assigment, call, increment etc?
От:
Аноним
Дата:
22.01.14 04:03
Оценка:
Почему нельзя писать?
a + b;
Как это могло бы пригодиться: например, чтобы заменить громоздкий условный if-else на компактный тернарный ?: при определении какой метод вызвать:
int a = 5;
int b = 10;
a == b ? doThis() : doThat()
P.S.: Как перевести statement на русский? (MSDN предлагает "оператор" )
P.P.S.: Как переключить язык статьи на MSDN на русский, кроме как заменить в URL "en-us" на "ru-ru"?
Re: Почему в качестве statement может быть только assigment, call, increment etc
Я философски против предоставления такого метода по двум причинам.
Во-первых, это нарушило бы принципы функционального программирования, на которых основаны все остальные операторы на последовательностях. Очевидно, что единственная цель вызова этого метода состоит в достижении побочных эффектов.
Цель выражения (expression) – вычислить значение, а не произвести побочный эффект. Цель оператора (statement) – вызвать побочный эффект. Место вызова этой штуки будет выглядеть весьма похоже на выражение (хотя, признаться, поскольку метод ничего не возвращает, выражение может использоваться только в контексте «операторного выражения» (statement expression)).
Мне как-то не нравится идея сделать единственный оператор для последовательностей, который полезен только для спецэффектов.
Очень советую прочитать (не пролистать, а именно прочитать) всю статью целиком.
А>P.S.: Как перевести statement на русский?
См перевод по ссылке выше. Обычно для неоднозначных терминов приводят и русский и английский вариант.
А>P.P.S.: Как переключить язык статьи на MSDN на русский, кроме как заменить в URL "en-us" на "ru-ru"?
Где-то внизу есть ссылка настроек, но быстрее поменять в адресной строке. Stackoverflow тоже не предлагает ничего полезного.
Re: Почему в качестве statement может быть только assigment, call, increment etc
Здравствуйте, Аноним, Вы писали:
А>Как это могло бы пригодиться: например, чтобы заменить громоздкий условный if-else на компактный тернарный ?: при определении какой метод вызвать:
Тогда уж лучше наоборот — выкинуть плохо читаемый тернарный оператор и оставить только if-else.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[2]: Почему в качестве statement может быть только assigment, call, increment
От:
Аноним
Дата:
22.01.14 08:54
Оценка:
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Аноним, Вы писали:
H>Тогда уж лучше наоборот — выкинуть плохо читаемый тернарный оператор и оставить только if-else.
Ну, т.е. в C++ это было можно, от этого были проблемы, поэтому в C# этого нельзя. Я вас правильно прочитал?
Частный случай мало интересен (кстати, вы правы насчет него), вопрос был поставлен в общем.
Re[3]: Почему в качестве statement может быть только assigment, call, increment
От:
Аноним
Дата:
22.01.14 09:03
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Ну, т.е. в C++ это было можно, от этого были проблемы, поэтому в C# этого нельзя. Я вас правильно прочитал? А>Частный случай мало интересен (кстати, вы правы насчет него), вопрос был поставлен в общем.
Для ясности. Частный случай это замена if-else на ?:, общий случай это невозможность писать код типа
2 + 3;
Re[4]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, Аноним, Вы писали:
А>>Частный случай мало интересен (кстати, вы правы насчет него), вопрос был поставлен в общем. А>Для ясности. Частный случай это замена if-else на ?:, общий случай это невозможность писать код типа А>
А>2 + 3;
А>
И что это в общем случае даст? Тут все верно было процитировано
Очевидно, что единственная цель вызова этого метода состоит в достижении побочных эффектов.
Если + и может играть тут какую-то роль, то явно только производя побочный эффект.
Re[2]: Почему в качестве statement может быть только assigment, call, increment
От:
Аноним
Дата:
22.01.14 09:38
Оценка:
Здравствуйте, Sinix, Вы писали:
S>Очень советую прочитать (не пролистать, а именно прочитать) всю статью целиком.
Но статья целиком о том, что foreach лучше .ForEach (тут он прав, конечно же. Хотя с другой стороны в комментариях можно найти и обоснованные возражения и его ответ в одном из них, что он упустил, что .ForEach может быть полезен когда ему на вход подается method group — комм. Steve Cooper).
С другой стороны выделенный вами фрагмент выглядит правдоподобно, но непонятно. Например, непонятно что такое "statement expression", гугл такого не находит. А если это идиома, то непонятно что она в данном контексте значит. > Место вызова этой штуки будет выглядеть весьма похоже на выражение (хотя, признаться, поскольку метод ничего не возвращает, выражение может использоваться только в контексте «операторного выражения» (statement expression)).
Также непонятно следующее. Допустим, цель вызвать побочные эффекты. Что это такое и чем это плохо? S>Во-первых, это нарушило бы принципы функционального программирования, на которых основаны все остальные операторы на последовательностях. Очевидно, что единственная цель вызова этого метода состоит в достижении побочных эффектов.
S>См перевод по ссылке выше. Обычно для неоднозначных терминов приводят и русский и английский вариант.
Спасибо. Действительно.
S>Где-то внизу есть ссылка настроек, но быстрее поменять в адресной строке. Stackoverflow тоже не предлагает ничего полезного.
Спасибо :3
Re[5]: Почему в качестве statement может быть только assigment, call, increment
От:
Аноним
Дата:
22.01.14 09:44
Оценка:
Здравствуйте, Doc, Вы писали:
Doc>И что это в общем случае даст? Тут все верно было процитировано Doc>
Очевидно, что единственная цель вызова этого метода состоит в достижении побочных эффектов.
Doc>Если + и может играть тут какую-то роль, то явно только производя побочный эффект.
Но то, что мы напишем так как требует компилятор не гарантирует его отсутствие:
var a = 2 + 3;
Re[3]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, Аноним, Вы писали:
А>Но статья целиком о том, что foreach лучше .ForEach
Неа. У Липперта просто стиль такой — разбирать всё на конкретных примерах. Те же доводы применимы к любым спорам на тему "statement === expression".
А> (тут он прав, конечно же. Хотя с другой стороны в комментариях можно найти и обоснованные возражения и его ответ в одном из них, что он упустил, что .ForEach может быть полезен когда ему на вход подается method group — комм. Steve Cooper).
Это всё-таки частные случаи, для них никто не мешает добавить свой хелпер.
А>С другой стороны выделенный вами фрагмент выглядит правдоподобно, но непонятно. Например, непонятно что такое "statement expression", гугл такого не находит. А если это идиома, то непонятно что она в данном контексте значит.
Это из спецификации шарпа. Например вот
>> Место вызова этой штуки будет выглядеть весьма похоже на выражение (хотя, признаться, поскольку метод ничего не возвращает, выражение может использоваться только в контексте «операторного выражения» (statement expression)). А>Также непонятно следующее. Допустим, цель вызвать побочные эффекты. Что это такое и чем это плохо?
1. Термин. Происхождение из медицины, см http://en.wikipedia.org/wiki/Side_effect
2. Тем, что вместо уже готового средства (стейтментов) мы используем выражения, причём крайне неочевидным способом. Не, серьёзно, кто будет писать
var a = new FailProvider();
a+b; // erases all data
// вместо
a.EraseAllData();
?
Re: Почему в качестве statement может быть только assigment, call, increment etc
Здравствуйте, Аноним, Вы писали:
А>Почему нельзя писать? А>
a + b;
Потому что так видят авторы C# и только, других причин нет.
В языках, где есть лишь expression-ы, компиляторы на подобный код рассказывают предупреждение о том, что результат операции игнорируется.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[6]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, Аноним, Вы писали:
А>Но то, что мы напишем так как требует компилятор не гарантирует его отсутствие: А>
А>var a = 2 + 3;
А>
А про гарантии никто не говорил. Там ключевое слово "единственная".
В данном случае мы еще получаем некую сумму, что скорее всего является целью данного кода.
Т.е. просто 2 + 3 скорее всего можно развернуть как
var r1 = 2;
var r2 = 3;
SomeSomeOp(r1,r2);
или вообще
[c#]DoSomeOp(2,3);[c#]
что IMHO более читабельно, чем просто 2+3, т.к. скорее всего DoSomeOp будет описывать суть процесса.
Re: Почему в качестве statement может быть только assigment, call, increment etc
Здравствуйте, Аноним, Вы писали:
А>Почему нельзя писать? А>
a + b;
Авторы пытались защитить программистов использующих шарп от ошибок. Так компилятор выявляет неверное использование.
А>Как это могло бы пригодиться: например, чтобы заменить громоздкий условный if-else на компактный тернарный ?: при определении какой метод вызвать: А>
А>int a = 5;
А>int b = 10;
А>a == b ? doThis() : doThat()
А>
Ты интитивным путем пришел к идее все есть выражение (everything is an expression), но наоборот.
Эта идея широко распростронена в функциональном мире. Она подразумевает полный отказ от стейтментов. Вместо них любое выражение может иметь тип void (в терминах шарпа).
Например, в Nemerle оператор if может использоваться и как стейтмент:
if (a == b)
DoThis();
else
DoThat();
и как выражение:
def x = if (a == b) GetThis() else GetThat();
В Nemerle не нужно (хотя и можно) использовать return. Функция возвращает значения вычесленные самими вложенными ветвями выражений. Например:
Это делает код более понятным и облегчает его чтение (все выходы из кода очевидны и предсказуемы).
Значением блока кода является его последний элемент, так что возможен вот такой прием:
Foo({ mutable value; dic.TryGetValue(key, out value); value });
А>P.S.: Как перевести statement на русский? (MSDN предлагает "оператор" )
Никак. Принятого перевода нет и большинство авторов превращают текст в кашу переводя statement как оператор, попутно так же переводя operator.
А>P.P.S.: Как переключить язык статьи на MSDN на русский, кроме как заменить в URL "en-us" на "ru-ru"?
Там сверху переключатель есть, вроде.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Почему в качестве statement может быть только assigment, call, increment
От:
Аноним
Дата:
23.01.14 03:37
Оценка:
Спасибо за развернутые ответы.
Re[7]: Почему в качестве statement может быть только assigment, call, increment
От:
Аноним
Дата:
23.01.14 03:47
Оценка:
Здравствуйте, Doc, Вы писали:
Doc>А про гарантии никто не говорил. Там ключевое слово "единственная". Doc>В данном случае мы еще получаем некую сумму, что скорее всего является целью данного кода.
Вы правы. Спасибо.
Re[2]: Почему в качестве statement может быть только assigment, call, increment
VD>Это делает код более понятным и облегчает его чтение (все выходы из кода очевидны и предсказуемы).
На nemerle не писал, поэтому как-то не заметил что данный код легко читаемый.
Не зная тонкостей языка сложно понять что он делает (и что есть 3 точки выхода).
А вот конструкция вида
if (a != b)
return M1(a, b);
else
return M2(a, b);
IMHO будет понятна большей части разрабочиков, писавших на C#, C/C++, JS, PHP, VB.
Re[2]: Почему в качестве statement может быть только assigment, call, increment
От:
Аноним
Дата:
23.01.14 03:59
Оценка:
Спасибо.
Re[3]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, Doc, Вы писали:
Doc>На nemerle не писал, поэтому как-то не заметил что данный код легко читаемый.
Это пока кода 5 строк. А когда его экраны, то отсутствие ретурнов в середине алгоритма очень облегчает его читаемость.
В прочем, конечно же "все есть выражение" только составная часть. Для повышения уровня языка этого явно недостаточно. В Немерле их до фига. Например, локальные функции или оператор "?." позволяющий избавиться от моря проверок на null.
Кое какие мелочи (например, упоминаемый оператор "?."), вроде как, планируются в следующей версии Шарпа. Но того же паттер-матчинга в ближайшее время не появится. А это мощнейшая вещь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Почему в качестве statement может быть только assigment, call, increment etc
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Doc, Вы писали:
Doc>>На nemerle не писал, поэтому как-то не заметил что данный код легко читаемый.
VD>Это пока кода 5 строк. А когда его экраны, то отсутствие ретурнов в середине алгоритма очень облегчает его читаемость.
Так вот и я о таком же случае. Как в коде скажем 20-30 строк сразу узреть такую точку выхода. return так видно + IDE подсвечивает. А в nemerle как?
Re[5]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, Doc, Вы писали:
Doc>Так вот и я о таком же случае. Как в коде скажем 20-30 строк сразу узреть такую точку выхода. return так видно + IDE подсвечивает. А в nemerle как?
IDE одинаково подсвечивает все ключевые слова. Выцепить глазами одиночный return из кучи кода практически невозможно. И код не весь в экран влезает. Я уже не говорю о фолдинге разном. Смотришь ты в конец некой функции и думаешь, а дойдет ли сюда управление?
А вот если ты знаешь, что return-ов нет в принципе, то ситуация в корне меняется. Ты уже знаешь, что выполнение не прервется где-то выше. И код начинает выглядеть по другому. В коде появляются четкие потоки управления. Ты точно знаешь, что если глядишь в конец функции, то раньше управление прерваться не могло. Все ветвления идут по if-ам и match-ам (аналогам switch-ей, но в сто раз более крутым). if без else вообще отдельная конструкция, которая принципиально императивна и прервать выполнение не может.
На мой взгляд return оправдан только в начале функции, как средство проверки граничных условий. Ну, или в очень маленькой функции (5-7 строк). В теле функции он вреден.
Теперь я и на Шарпе пишу по другому. Хотя шарп, конечно, провоцирует на использование return, continue и прочих императивных конструкций.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, VladD2, Вы писали:
VD>А вот если ты знаешь, что return-ов нет в принципе, то ситуация в корне меняется.
Хочу уточнить один момент — ты выше пишешь, что в Немерле ретурн использовать можно. То есть гарантий (что его не будет) всё-таки нет? Или он там ведёт себя как-то иначе?
Re[6]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, VladD2, Вы писали:
VD>А вот если ты знаешь, что return-ов нет в принципе, то ситуация в корне меняется. Ты уже знаешь, что выполнение не прервется где-то выше.
Т.е. в исходном примере точки true, false и name1.Equals(name2) не являются прерывающими?
VD>И код начинает выглядеть по другому. В коде появляются четкие потоки управления.
Здравствуйте, IT, Вы писали:
Doc>>На nemerle не писал, поэтому как-то не заметил что данный код легко читаемый. IT>Это быстро проходит.
Ну с привычной и asm читать легко
IT>Синтаксис лямбд в C# уже не требует return и как-то все до сих пор живы и счастливы. Так что return действительно лишний элемент в языке.
Что-то не встречал лямбд в экране высотой.
Re[5]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, Doc, Вы писали:
Doc>>>На nemerle не писал, поэтому как-то не заметил что данный код легко читаемый. IT>>Это быстро проходит. Doc>Ну с привычной и asm читать легко
Это так. С другой стороны некоторые, чтобы доказать всем правильность своих суждений, любят отрицать очевидные вещи, в которых сами ничего не понимают.
IT>>Синтаксис лямбд в C# уже не требует return и как-то все до сих пор живы и счастливы. Так что return действительно лишний элемент в языке. Doc>Что-то не встречал лямбд в экране высотой.
У тебя есть прибор для измерения правильности лямбд? Дай попользоваться.
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, DarkEld3r, Вы писали:
VD>>А вот если ты знаешь, что return-ов нет в принципе, то ситуация в корне меняется. DE>Хочу уточнить один момент — ты выше пишешь, что в Немерле ретурн использовать можно. То есть гарантий (что его не будет) всё-таки нет? Или он там ведёт себя как-то иначе?
return в Немерле представляет собой подключаемый макрос и для его использования нужно сделать определённые телодвижения. Отличие одно — им можно сделать выход из глубин вложенности, что само по себе уже является функциональной ересью.
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, DarkEld3r, Вы писали:
DE>Хочу уточнить один момент — ты выше пишешь, что в Немерле ретурн использовать можно. То есть гарантий (что его не будет) всё-таки нет? Или он там ведёт себя как-то иначе?
Дело в том, что return, continue, break реализованы в виде макросов. Для использования return, continue, break нужно открыть (using-ом) пространство имен Nemerle.Imperative.
В коде может быть именованный блок:
public FirstFailedIndex : int
{
get
{
ret:
{
def state = _parseResult.ast[AstPointer + 2];
when (state != ParseResult.AstParsedState)
{
foreach (rule in Sequence.Subrules with i)
when (rule.State > state)
ret(i - 1);
ret(Sequence.Subrules.Length - 1);
}
-1
}
}
}
На практике, они встречаются очень редко.
Кроме того в команде вырабатывается соглашение (у нас оно негласно выработалось) не применять return, continue, break или именованные блоки внутри больших функций и вообще, без особой необходимости. Так что на практике можно быть уверенным, что код их не содержит.
Хотя есть код где не только return, но и goto есть. Мне даже пришлось реализовать макрос goto для этого, так как раньше в языке goto не поддерживалось. Wolfhound считает, что с ними писать алгоритмы парсинга проще. В основном это генерируемый код. Но 7 goto в гражданском коде есть .
В общем, ничего не должно становиться догмой. 99% нашего кода не имеет даже return-ов, но это не означает, что мы совсем против него. Просто это дает реальные преимущества на практике.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Почему в качестве statement может быть только assigment, call, increment
то функция всегда будет возвращать true, а компилятор выдаст предупреждение о том, что значение выражения "if..." теряется.
Первое время это не привычно, но потом не понимаешь как жил без этого раньше.
Doc>Ну тогда это вполне реализуемо и на C# Doc>
Для частного случая — да. В общем, это очень неудобно/невозможно и никто так писать не будет. А для приведенного случая и return-ы сойдут. Тут ведь весь код на ладони.
Doc>Хотя кончено, как говориться, на вкус и цвет товарищей нет.
Все знакомые кто пробовал так писать дольше месяца сходятся во мнении, что "return не нужен". Как правильно сказал IT в лямбдах шарпа тоже обходятся без return-ов и не видят в этом проблемы. Это просто шаг к улучшению поддержки функционального стиля программирования.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, IT, Вы писали:
IT>Это так. С другой стороны некоторые, чтобы доказать всем правильность своих суждений, любят отрицать очевидные вещи, в которых сами ничего не понимают.
Проблема в том, что очевидны они только для тех кто сам на практике их познал. А для теоретизирующих они не очевидны. Более того, даже краткое знакомство не поможет оценить многие решения. Ведь для их оценки нужно немного перестроить сознание. А для этого нужно время и практика.
Обычно понимание приходит когда возвращаться обратно. Никак не забуду тот батхерт/ломку когда после месячного программирования на Немерле вызвал обратный переход на Шарп. Казалось что мне выкрутили руки. Потом привык и стал относиться даже как-то по философски. Но первая реакция была просто потрясающей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, IT, Вы писали:
IT>Это так. С другой стороны некоторые, чтобы доказать всем правильность своих суждений, любят отрицать очевидные вещи, в которых сами ничего не понимают.
Эк куда тебя понясло. Куча воды и не слова по сути.
Doc>>Что-то не встречал лямбд в экране высотой. IT>У тебя есть прибор для измерения правильности лямбд? Дай попользоваться.
Как "измерение правильности лямбд" относится к объему кода?
Re[8]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, VladD2, Вы писали:
VD>Первое время это не привычно, но потом не понимаешь как жил без этого раньше.
Со стороны больше похоже на "сахар". Если подставить return, то, за рядом моментов, получится C# код.
VD>Тут ведь весь код на ладони.
Если код не влезает в экран, то для меня это повод задуматься над его разделением на методы.
VD>Все знакомые кто пробовал так писать дольше месяца сходятся во мнении, что "return не нужен". Как правильно сказал IT в лямбдах шарпа тоже обходятся без return-ов и не видят в этом проблемы.
Только стоит еще отметить, что там обычно несколько строк кода, а то и вовсе что-то вроде a+b.
VD>Это просто шаг к улучшению поддержки функционального стиля программирования.
Заинтересовали, если вдруг найду время — попробую
Re[7]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, Doc, Вы писали:
IT>>Это так. С другой стороны некоторые, чтобы доказать всем правильность своих суждений, любят отрицать очевидные вещи, в которых сами ничего не понимают. Doc>Эк куда тебя понясло. Куча воды и не слова по сути.
Началось.
Doc>>>Что-то не встречал лямбд в экране высотой. IT>>У тебя есть прибор для измерения правильности лямбд? Дай попользоваться. Doc>Как "измерение правильности лямбд" относится к объему кода?
Какое отношение имеет экран к лямбдам?
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, Doc, Вы писали:
Doc>Просто — объем кода. Переспрошу — у тебя часто получаются / встречаются лямбды занимающие весь экран (где-то 50 строк кода).
А почему не 49 или 51?
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, Doc, Вы писали:
Doc>Кстати, под VS2013 планы есть? Что-то не хочется 12 ставить ради попробовать.
Для 2013 сборка есть, но он пока не автоматизирована. Вручную можно из исходников собрать.
Качаешь репозиторий (он большой) и запускаешь BuildInstallerFast-4.5.1.cmd (чтобы собрать инсталлятор) или DevBuildQuick-4.5.1.cmd (чтобы собрать и зарегистрировать отладочную весрию).
Doc>+ на nemerle.org страница Wiki дает 404
У меня все ОК. Видимо работы какие-то велись.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, Doc, Вы писали:
Doc>Но ты опять в сторону — сколько строк в среднем занимают у тебя (написанным тобой коде, не тобой но с которым ты работаешь) лямбды, а сколько функции?
Я не считал. А тебе зачем? Ты можешь сразу озвучить свою мысль без этих вихляний? Если она у тебя, конечно, есть.
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, IT, Вы писали:
IT>Я не считал. А тебе зачем? Ты можешь сразу озвучить свою мысль без этих вихляний? Если она у тебя, конечно, есть.
Забыл что тебе все разжевывать надо Речь о том, что лямбда это как правило небольшая. А в этом случае даже "и return-ы сойдут".
Более того, лямбды без return как правило имеют вид x => DoSomething(x), т.е. не содержат if и прочих конструкций как в исходном примере.
Re[3]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, Doc, Вы писали:
IT>>Я не считал. А тебе зачем? Ты можешь сразу озвучить свою мысль без этих вихляний? Если она у тебя, конечно, есть.
Doc>Забыл что тебе все разжевывать надо Речь о том, что лямбда это как правило небольшая. А в этом случае даже "и return-ы сойдут". Doc>Более того, лямбды без return как правило имеют вид x => DoSomething(x), т.е. не содержат if и прочих конструкций как в исходном примере.
Ну и где тут мысль?
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Почему в качестве statement может быть только assigment, call, increment
Здравствуйте, IT, Вы писали:
Doc>>Более того, лямбды без return как правило имеют вид x => DoSomething(x), т.е. не содержат if и прочих конструкций как в исходном примере. IT>Ну и где тут мысль?
Что ты совсем не в тему с однострочными лямбдами без return, когда речь шла о методах с блоками if.