Ты полностью пропускаешь мой поинт...

Можно и си-кастом.

Но не нужно.

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

Почти. Я не думаю, что он корректен. Работает =/= корректен. Там могут быть какие-то чудовищно странные пункты стандарта, что сработает Hyrum’s law и будет какой-нибудь компилятор, который всё сломает.

Безопасный даункаст делается через static_cast, энд оф стори.

А разве каст void* -> T* - это даункаст?

Даункаст — это не термин из стандарта. Поэтому я не уверен, что на это стоит завязываться.

Но идея в целом, что типы преобразовывать надо через статик_каст

Если я правильно понял этот пункт, static_cast может изменить значение указателя только если было нарушено выравнивание. Здесь я говорю только о касте void* -> T*.

Но да, я с ходу не вижу зачем там был лишний уровень индерекции, а без него конечно лучше статиком пользоваться.

reinterpret_cast?

На самом деле скорее всего правильный ответ вообще заключается в использовании placement new, но без контекста сложно что-либо утверждать.

Я не понял вопроса.

Говорю, может стоит использовать reinterpret_cast для таких целей?

reinterpret_cast почти всегда плохая идея, в этом я согласен с @AndreiKei. Я спорил только с техническими мелочами.

Более того, reinterpret_cast очень редко бывает нужен. С ходу я могу назвать только одно разумное применение intptr_t <-> T*.

кстати, std::bit_cast все кейсы reinterpret_cast закрывает?

Опять туплю. Еще конечно T* <-> char* и аналогичные типы.

Поцоны, вопрос по дизайну и архитектуре. У приложения есть большая функция с кучей проверок на то что входящие данные валидны. Проходит какое-то время и нужно написать вторую функцию, которая делает на 90% то же самое что и первая но немного иначе. Проходит еще время - нужно расширить еще в другом месте. Как правильно сделать архитектуру для этого? Вот несколько вариантов которые мне кажутся не оч.
1. Добавить больше аргументов. Мне не нравится потому что много аргументов будут  релевантны только в одном частном случае и бойлерплейтом в других.
2. Разбить на мелкие функции и вместо условного validate(args...) вызывать validateA(aArgs...) && vallidateB(bArgs...) && validateC(cArgs...). Минусом я вижу что если появится нужда для validateD(dArgs...) в будущем то нужно будет его добавлять во множестве разных мест.

может какой-то policy-based здесь подойдет?