struct I { virtual void foo() { /* nothing */ } };
struct A : I { void foo() final { /* impl */ } };
struct B : I { /* no foo */ };

struct A { void foo() { /* impl */ } };
struct B { /* no foo */ };

придется ждать метаклассы)
https://www.youtube.com/watch?v=drt3yXI-fqk

а как метаклассы решат проблему?
статические проверки и сейчас можно сделать

Andrey здравствуйте. В очередной раз хочу поднять тему нулевого указателя.
Примеры кода, поведение которых хотелось бы у вас прояснить (по возможности со ссылками на стандарт):

A *p{nullptr};
*p; // 1
std::cout << (*p, 5); // 2
A a{*p}; // 3
p->non_static_mem_fn(); // 4
p->static_mem_fn(); // 5

Что, кажется, удалось выяснить к настоящему моменту:
Пример 1
Согласно expr.unary.op.1, разыменование возвращает an lvalue referring to the object or function to which the expression points. Есть трактовка, что раз объекта нет, то UB, но, например, dangling ссылки сами по себе не UB несмотря на то, что исходного объекта нет. Еще есть довольно старая CWG issue 232, где CWG пришла к неформальному консенсусу, что p = 0; *p; is not inherently an error. Полагаю, что в этом примере UB нет.

Пример 2
Видно две потенциальные возможности UB. Разыменование освещено в предыдущем примере, поэтому здесь сфокусируюсь на операторе запятая. Согласно expr.comma.1, операнды вычисляются слева направо, и то, что вернуло разыменование, становится discarded-value выражением. Неформальный консенсус в CWG issue 232 также в том, что an lvalue-to-rvalue conversion would give it undefined behavior, но и его не происходит, потому что о volatile речь у нас нигде не идет (expr.context-2), не говоря о том, что в текущем тексте стандарта этот консенсус, кажется, тоже не отражен: в conv.lval из релевантного только the value contained in the referenced object is not accessed, что наоборот предупреждает возможность UB (basic.lval.11). Полагаю, что UB нет и здесь.

Пример 3
Полагаю, здесь UB начнется самое позднее на попытке доступа к несуществующему объекту под p внутри конструктора копирования согласно basic.lval.11.

Пример 4
Полагаю, здесь UB начнется в момент вызова функции-члена у несуществующего объекта согласно class.mfct.non-static.1.

Пример 5
Если предположить, что разыменование, которое происходит согласно 59 сноске, само по себе допустимо, то далее я не нахожу требований, чтобы сам объект существовал, и, соответственно, причин для UB.

struct I { virtual void foo() { /* nothing */ } };
struct A : I { void foo() final { /* impl */ } };
struct B : I { /* no foo */ };

struct A { void foo() { /* impl */ } };
struct B { /* no foo */ };

Аналог финала я помню хотел как бумажку в ИСО оформить

Я бы лично предложил комитету ограничиться явной формулировкой, что ссылка в момент формирования должна указывать на объект соответствующего типа

Я не понимаю ни одного случая, когда в разумных целях нужно нарушать это правило

по-моему, оно есть
dangling reference тут не с той целью упоминается

Но если есть, то *p в (1) это немедленно UB. *nullptr не указывает на объект какого-либо типа

ссылки идут как пример lvalue, которые могут не указывать на объект

Они могут не указывать, но не в момент формирования, я же это и пишу.

Мы не можем обеспечить ссылочный контроль, но нет никакой причины разрешать формальное разыменование просто потому, что это операция "ничего не сделать"

В частности, если разыменование это операция "ничего не сделать", мы только что стандартизировали весь ABI ссылок

я предлагаю не уходить от темы в ссылки, которые лишь частный случай lvalue

мне кажется, что последствием ни к чему не обязывающего разыменования немедленно становится эквивалентность ссылок и указателей в ABI

мы можем инициализировать ссылку любым указателем, а любой указатель преобразовать в ссылку

а ссылки и так указатели в itanium abi, насколько я помню

это undefined для стандарта

может быть
но я очень не хочу, чтобы мы сейчас ушли в эту частность