Видны большие синтаксические изменения TypeScript 1.5 в плане модулей. Это позволит более тонкую интеграцию с ангуляровскими компонентами? Замечательно! А где можно почитать про изменения в 1.5?
Только что проверил вот на такой простой программе:
class Program
{
static int Recursive(int x)
{
if (x == int.MaxValue)
{
throw new Exception();
}
return Recursive(x + 1);
}
static void Main(string[] args)
{
int x = Recursive(0);
Console.WriteLine(x);
}
}
В AnyCPU под 64-битной осью оптимизация не срабатывает, в дебаге — тоже. Если компилять под x64-only и в релиз — тогда начинает работать. Стек действительно портится — показывает, что упал в Main -> Recursive без отслеживания хвостовых вызовов. Ну что ж, нормально — лучше уж так, чем вообще без оптимизации.
Вообще говоря, мне не кажется, что TCO такая уж важная вещь в .NET именно по причине того, что она не гарантируется. Вот если она будет гарантирована стандартом в каких-то случаях, или же можно будет развесить какие-то атрибуты, которые бы проверяли её наличие и падали, если оптимизировать не получилось (типа @tailrec в Scala) — это было бы нормально. Моя мотивация проста — TCO это крайне важная особенность поведения кода, которая может сильно влиять на его быстродействие и характеристики потребления памяти, ну а писать рабочий код, который полагается на какие-то негарантированные оптимизации компилятора и ломается, если у компилятора или JIT'тера что-то там «не получилось» — это уж слишком, по-моему.
Вспомнил ещё, что JIT-x64 иногда умеет оптимизировать хвостовую рекурсию, что может приводить к неожиданно успешному выполнению очень глубоких рекурсивных вызовов, непредсказуемому влиянию на производительность и т.п. весёлым вещам.
(Интересно, кстати, что при этом будет в стектрейсе — будет ли рантайм наворачивать туда фреймы от хвостового вызова или нет.)
Кстати, кто знает, как в RjuJIT с tail recursion? Он умеет .tailcall или, может быть, сам умеет оптимизировать какие-то простые случаи?
В ином контексте, действительно, очевидно, что ссылка на пустой массив приведётся к true. Но в контексте JS и с учётом того, что пустая строка равна false, для меня это очевидным быть перестаёт (пустая строка для меня, уж простите, по-паскалевски ассоциируется с пустым массивом символов, как бы это ни было семантически отдалено в современных языках и рантаймах — хотя вот в Haskell или Erlang, например, это соответствие идеально прослеживается).
В целом я с вами согласен — конечно, всегда можно нагородить море проверок перед вызовом метода, чтобы не было падений при вызове методов и обращении к свойствам. И вот ещё, кстати, C#6 не предлагает полноценного решения описанной вами проблемы — обращения к свойству только если индекс присутствует в массиве. Кстати пришёлся бы синтаксис наподобие
someArray?[index]?.Foo()?.Bar()
Однако в целом начинание, на мой взгляд, неплохое. Мне в реальности довольно часто приходится городить этажерки из трёх-четырёх проверок на null перед вызовом свойств, как бы неприятно это ни было. И отлично, что C#6 мне поможет сократить количество такого кода.
Да, вычисление будет только один раз. Противоположное поведение бы разрушило семантику оператора точки, и это было бы вообще печально. Выше товарищ привёл разбор декомпилированного кода, ознакомьтесь.
С ECMA-языками на самом деле начинается полный трэш и угар — оказывается, что пустая строка равна false, а пустой массив — true, ну и так далее по списку (где-то, кажись, даже строка '0' равнялась false). Остерегайтесь применения булева контекста к неизвестным объектам, друзья. Это может закончиться болью.
А вы попробуйте сами, соберите. Этот пример кода довольно старый (но я проверил — на компиляторе из VS 2013 воспроизводится); пару лет назад я хотел было разобраться, что ж там такое хранится, но тогдашний рефлектор не сумел разобрать такую большую сборку, на том исследования в тот раз и закончились.
Мне очень жаль, что вы узнаёте эту новость от меня, но, к сожалению, гитхаб уже заблокирован некоторыми провайдерами. Лично у меня он уже примерно сутки недоступен (конечно, я принял соответствующие меры, но сам факт остаётся).
Разные провайдеры на территории РФ принимают разные меры по блокировке, некоторые могли ещё не успеть заблокировать — спасибо им хоть на этом.
В AnyCPU под 64-битной осью оптимизация не срабатывает, в дебаге — тоже. Если компилять под x64-only и в релиз — тогда начинает работать. Стек действительно портится — показывает, что упал в
Main -> Recursiveбез отслеживания хвостовых вызовов. Ну что ж, нормально — лучше уж так, чем вообще без оптимизации.Вообще говоря, мне не кажется, что TCO такая уж важная вещь в .NET именно по причине того, что она не гарантируется. Вот если она будет гарантирована стандартом в каких-то случаях, или же можно будет развесить какие-то атрибуты, которые бы проверяли её наличие и падали, если оптимизировать не получилось (типа
@tailrecв Scala) — это было бы нормально. Моя мотивация проста — TCO это крайне важная особенность поведения кода, которая может сильно влиять на его быстродействие и характеристики потребления памяти, ну а писать рабочий код, который полагается на какие-то негарантированные оптимизации компилятора и ломается, если у компилятора или JIT'тера что-то там «не получилось» — это уж слишком, по-моему.(Интересно, кстати, что при этом будет в стектрейсе — будет ли рантайм наворачивать туда фреймы от хвостового вызова или нет.)
Кстати, кто знает, как в RjuJIT с tail recursion? Он умеет
.tailcallили, может быть, сам умеет оптимизировать какие-то простые случаи?false, для меня это очевидным быть перестаёт (пустая строка для меня, уж простите, по-паскалевски ассоциируется с пустым массивом символов, как бы это ни было семантически отдалено в современных языках и рантаймах — хотя вот в Haskell или Erlang, например, это соответствие идеально прослеживается).В целом я с вами согласен — конечно, всегда можно нагородить море проверок перед вызовом метода, чтобы не было падений при вызове методов и обращении к свойствам. И вот ещё, кстати, C#6 не предлагает полноценного решения описанной вами проблемы — обращения к свойству только если индекс присутствует в массиве. Кстати пришёлся бы синтаксис наподобие
Однако в целом начинание, на мой взгляд, неплохое. Мне в реальности довольно часто приходится городить этажерки из трёх-четырёх проверок на
nullперед вызовом свойств, как бы неприятно это ни было. И отлично, что C#6 мне поможет сократить количество такого кода.false, а пустой массив —true, ну и так далее по списку (где-то, кажись, даже строка'0'равняласьfalse). Остерегайтесь применения булева контекста к неизвестным объектам, друзья. Это может закончиться болью.И — вуаля, сборочка весит уже 29 мегабайт. Можно растаращить ещё больше, но это я оставлю в качестве упражнения для читателя :)
Разные провайдеры на территории РФ принимают разные меры по блокировке, некоторые могли ещё не успеть заблокировать — спасибо им хоть на этом.
Эх, я думаю, многие ранее считали, что и гитхаб «слишком крупный, чтобы его заблокировать» :(