1. С какого это бодуна мы хотим, чтобы не было побочных эффектов? Побочный эффект - нормальный инструмент в программировании.
Ну да, используешь какую-нибудь функцию в выражении, а она зараза втихаря нужный файл закрывает или еще что-нибудь в этом роде творит. Вполне себе нормально! Если есть возможность такие вещи поставить под контроль, то почему нет? Хотим без страховки бегать по перилам, чтобы круче выглядеть в глазах окружающих?
Дык. Желание понятно. Метод решения - нет. Ну допустим вы запретите обращаться к "внешним" сущностям из "функций". От "закрытия файла" это не спасет. Всегда можно спустить в качестве аргумента ну очень абстрактный интерфейс, вызов метода которого закроет файл. Никакого контроля. Ограничить аргументы простыми неуказательными типами? Тогда толку от таких "функций" будет ничтожно мало.
Я понимаю, что тем, кто съел собаку на C/C++, теперь море по колено, и они такими мелочами, как наглядность, не заморачиваются.
Не надо обвинять плюсистов в настолько страшных грехах
Они все люди и наглядность кода им тоже важна. И именно поэтому я считаю, что оберон еще пилить и пилить
Оберон уже на три порядка нагляднее C/C++, чего же, дескать, еще желать?
Давайте не будем в этом топике
Ограничимся функциями и процедурами (хотя это тоже уже неоригинальный топик).
Но у людей, не прошедших эти медные трубы, требования к наглядности (и надежности!) более высокие.
Описываемую проблему ("неожиданное закрытие файла") я, будучи на С++, решаю такими самоограничениями:
1. Минимум глобальных переменных. Это значит, что функция не может закрыть файл, если только к ней через аргумент не пришло что-то, что можно использовать для закрытия файла.
2. По возможности аргументы делаются const. Это уменьшает вероятность того, что функция сделает что-то деструктивное даже используя такие аргументы.
Да, мне хотелось бы больше контроля. Поэтому я пытаюсь понять чем же мне может помочь разделение на процедуры и функции. Но пока я не вижу никакой реальной помощи, кроме чисто умозрительного "функция не будет закрывать файл, потому что она функция, а не процедура".