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

V>Потому что чудес не бывает.
V>Нельзя одновременно хотеть надёжности не хотеть её.
Ответ неверный.

S>>И сколько будет проверок, если вместо вызова Console.WriteLine поставить что-то типа s+=array[i], как в исходных примерах?
V>И это всё еще хуже, чем array.AsSpan(range) по целому комплексу причин, перечисленных мной.
Ну, то есть вы осознали, что промахнулись про эффективность, пришлось переводить разговор на "комплекс причин". Ок, засчитано.

V>Он всего лишь пытается сохранить семантику, даже если семантика содержит ошибку.
Во-первых, с чего вы взяли, что "семантика содержит ошибку"? Возможно, автор так и хотел — вывести не более чем N строк, а AIOOBE успещно перехватывается где-то выше по стеку.
V>А мы рассуждали о способах эти ошибки избегать.
Во-вторых, никакого обсуждения способов избегания ошибок не было. Не считать же, в самом деле, выброс AOORE вместо AIOOBE каким-то там "избеганием".
V>Видишь насколько дешевы твои манипуляции? ))
Вижу, насколько дёшевы ваши.

V>И да, если тело цикла чуть больше тривиального — он не порождает два варианта, порождается лишь "тяжеловесный".
Давайте посмотрим на какой-нибудь реальный пример.

V>Причём, даже в случае простейшего s+=item, если накопленная сумма s будет доступна и после выброса исключения, то в этот ошибочный вариант заходит и долго пыхтит перед тем, как выбросить исключение.
Повторю неочевидную для вас вещь: такое поведение связано не с плохим качеством оптимизатора, а с требованиями стандарта. "Ошибочность" варианта локально оценить невозможно.
V>А на деле, уровнем выше, эта s уже не нужна, но JIT не способен смотреть слишком далеко, пытаясь разгадать намерения программиста.
JIT способен смотреть ровно настолько, сколько попало в его поле зрения. Как, впрочем, и более-менее любой компилятор. Чтобы любой компилятор понял, что s уже не нужна, ему нужно "видеть" весь использующий её код.
Стандартная методика для оптимизаций обсуждаемого типа — инлайнинг. Работает это и в JIT-ах дотнета и джавы, и в GCC, и в LLVM. Нет инлайнинга — нет возможности гарантировать отсутствие побочных эффектов — будь любезен породить семантически корректный код.

V>Ес-но, мы же о безопасности рассуждали.
Неа, вы рассуждали об эффективности. Но пытаетесь мухлевать, как обычно.

V>За это тебя и не любят в спорах.
За то, что я внимательно читаю, и точно пишу?

V>Разумеется, можно вручную обвешать код проверками и облегчить жизнь JIT-у.

V>А еще можно вспомнить, что это стало работать вот совсем недавно по меркам жизни дотнета, что сколько я ни смотрел тщательно на выхлоп в течении двух десятков лет — он рожал "тяжелый" цикл, собака.

V>А еще коммерческие продукты должны поддерживать все дотнетные версии, которые официально в ходу, т.е. приходилось ориентироваться на то, что происходит, скажем, в .Net Core 3.1, даже когда уже вышел .Net 6.0.



V>У меня сейчас такое ощущение, что мы с тобой поменялись местами в споре — я топлю за безопасность и выразительность, а ты возражаешь "но если постараться, то ведь можно и ручками допилить примерно до такого же".
Не, вы одновременно мухлюете в нескольких направлениях. Например, делаете вид, что не пытались выдать устаревшие знания про оптимизацию циклов в дотнете за какие-то особенные знания, одновременно делая вид, что два кода, выбрасывающих исключения, чем-то отличаются друг от друга в плане безопасности.

V>Ну так решение может принять программист.
Может, конечно.
V>Просто ты никак не можешь под этим подписаться, бгг...
Нет, просто утверждение про то, что Span — более эффективный способ итерироваться по массиву устарело примерно тогда же, когда в джит завезли собственно оптимизации Span.

V>Мне забавно, конечно, что ты как аргумент предъявляешь то, что JIT честно пытается выполнить некорректный код.
V>При том, что мы до этого обсуждали, как сделать код более корректным.
И как вы определяете, какой из сниппетов более корректный?
V>Ладно, тут всё ясно.
Отож.