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

R>Но если в будущем появляется еще и тип C, также производный от A, и вы попытаетесь написать для него форматтер, похожий на тот, который уже написали для A, вы тут же почувствуете неудобство — этого нельзя будет сделать, не модифицировав специализацию форматтера для A, потому что обе специализации окажутся равноправны и создадут коллизию. Этого не произошло бы с функциями.

Это вообще зыбкая почва для споров. Если мы оперируем традиционным полиморфизмом, то надобность в отдельном форматтере для C вызывает вопросы. Если мы используем наследование не для полиморфизма, а для переиспользования функционала из базового класса в производных, то вопросы вызывает форматтер для A, который может форматировать и экземпляры классов-наследников.

В общем, возвращаемся в исходную точку: без примеров кода и реальных юз-кейсов все это теоритизирование. Типа можно было бы и лучше, но зачем и какой ценой хз.

Не пытаясь защищать fmtlib и std::format (мне процедура написания собственных специализаций formatter-а кажется неудобной) все же есть ощущение, что в процессе эволюции fmtlib и прохождение через комитет наверняка высказывались самые разные идеи, а на практике выжила имеющаяся комбинация возможностей + сложность реализации + накладные расходы.

R>P.S. И виртуальность вы напрасно сюда внесли, имхо.

Пример из документации к fmtlib, я его просто скопипастил. Все претензии к Зверовичу.