Ок, спасибо, буду знать

ну было бы лучше еслиб в стандарте был именно constexpr else наверн

Всем привет может кто то помочь с кодом проблема такая  а можно как то поменять переменную в switch (data2)?

чтоб после второго прохождения программы было switch (data1)

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

Поможет кто то мне с проблемой?

Потому что не любая constexpr функция вычисляется в компилтайме, соответственно, для рантайма тоже нужно рассчитать все возможные пути исполнения.
Это в общем случае невозможно.

Соответственно, не зачем заставлять компилятор что-то гадать в очень редких случаях хотя бы потому что компиляторы начнут делать это по разному и оно всё-равно не будет работать

if constexpr гарантировано выполняется компилятором, выкидывая одну из веток, не зависимо от того, функция выполняется в рантайме или компилтайме, соответственно, тут он точно знает ветвь исполнения, а не гадает

Есть еще более простой аргумент: int foo() {} до сих пор не является ошибкой компиляции по той же причине.

В теории да. Ничего сверхъестественного там не будет в плане зависимостей

Ну вот если соберёшь стат. либу с hidden и потом соберёшь shared с ней, то символы из стат. либы, явно не помеченные как visible, будут не видны клиентам shared либы. Вроде так это работает

В std::priority_queue можно изменить все элементы, без использования второго контейнера для временного хранения?

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

от std контейнеров не рекомендуют наследование

тогда почему внутренний контейнер в protected а не в private, если не предполагалось наследование?

наследоваться можно, насколько я помню, но хорошо ли — вопрос

Приватно можно отнаследоваться без проблем

а что плохого

я сам не скажу
по-моему, здесь обсуждали

std::priority_queue это не контейнер