Vlad- Вы про это говорили? В этой статье речь идет о формальном контороле на этапе компиляции отсутствия в тексте реализации глобальных сущностей (не передаваемых через интерфейс), Если используются внешние функции внутри реализации то возможность компиляции кода определяется сигнатурой вызова этой функции (если она помечена как чистая компиляция идет успешно). Вас такое решение устроит?
Устроит, как только я пойму как будет работать такое:
struct X
{
virtual void do() = 0;
};
void f(X &x) // pure или не pure?
{
x.do();
}
Еще раз хочу заметить: по моему убеждению мы не можем пометить X::do как pure, потому что мы не знаем заранее - сможет ли ее наследник реализовать как pure.
Почти тоже самое в другой формулировке (без ООП):
void f(F prediacte); // f может быть pure только если F - тоже pure
Что делать, если нам нужно вызвать f, а на руках у нас не-pure predicate?
1. Не чистая - просто потому что она (Do) обьявлена без модификатора
Если я f() объявлю как pure, то что будет:
1. Не скомпилится (вызов x.do() - не-pure)
2. Ошибка в рантайме, если конкретная реализация x.do является не-pure
Если 1 - то это то, о чем я говорил в самом начале (мало для чего можно использовать такие pure функции).
Если 2 - то мне такое принципиально не нравится
2.Просто f не обьявлять как чистую
Тогда приходим к тому, что любой обобщенный (библиотечный) код у нас будет не-pure. Т.е. использование pure сведется к каким-то мелким локальным вещам.