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

N>>В вашей реплике есть принципиальная ошибка и подтасовка
A>Вот как удивительно: а я увидел подстасовку в приведении такого примера, где ошибку совершать нельзя. И показал в ответ, как это обойти.

Просто "обойти" было и так очевидно, как. А вот чтобы это было эффективно для кодирования, отладки и сопровождения — уже нет.

A>А вообще, тезис в том, что (ИМХО) не надо на компиляцию возлагать больших надежд, связанных с проверкой корректности функционирования программы. Что может проверить компилятор?

Очень многое.

A> Соответствие грамматике и т.п. К правильному функционированию это имеет оооооочень опосредованное отношение.

Если компилятор запрещает присвоение числа строке или числу строки, это "соответствие грамматике" или таки "правильное функционирование"?
А мало какой язык такое разрешит.
Значит, проверка типизации возможна и полезна. Почему бы её не расширить?

A> Чекеры это уже лучше, это уже тесты, хоть и чисто модульные. А основные выводы о готовности к проду надо делать по результатам интеграционных.

О готовности — да, может быть.
Но ошибка найденная юнит-тестами обходится в разы дешевле, чем найденная интеграционными, та — чем у QA, а та в свою очередь — чем у заказчика/пользователя.
А пойманная ещё при компиляции — в разы дешевле, чем найденная юнит-тестами.
Отсюда очевидно, куда стоит вкладываться.

A>А поскольку я сторонник подхода, что если что-то работает ненадёжно, то и использовать это не надо

А оно работает ненадёжно? Это где и когда?

A> (идея та же, по которой люди запрещают security through obscurity),

Не вижу связи.

A> я считаю, что не стоит использовать все эти a: int 1..100 ни для чего, кроме как для декларации о намерениях (а вот для этого — надо). По сути, можно в имени или комментарии то же написать, но просто менее удобно. Ну, ещё логгер нарушений для дебажной версии, раз он всё равно халявный, но чисто для удобства отладки, не для выяснения, есть ли ошибки.

Я надеюсь, с таким подходом вы ничего серьёзного не разрабатываете...