Почему оператор if constexpr не устраняет эту ошибку основного константного выражения?

В стандарте мало что говорится о заявлении об исключении if constexpr. По сути, в [stmt.if] есть два утверждения об этом:

1. Во вмещающем шаблоне экземпляры отброшенных операторов не создаются.
2. Имена, на которые ссылается отвергнутый оператор, не требуют определения ODR.

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

template <typename T>
void f() {
    constexpr int x = -1;
    if constexpr (x >= 0){
        constexpr int y = 1<<x;
    }
}

Однако, если вы сделаете x зависимым от типа T, это нормально, даже если f создается с int:

template <typename T>
void f() {
    constexpr T x = -1;
    if constexpr (x >= 0){
        constexpr int y = 1<<x;
    }
}
int main() {
    f<int>();
}

Обратите внимание, что для утверждения, отклоненного Constexpr If:

отвергнутое утверждение не может быть неправильно сформировано для каждой возможной специализации:

Чтобы исправить проблему, вы можете сделать заявление в зависимости от параметра шаблона, например

template<typename T, int X> struct dependent_value { constexpr static int V = X; };

template <typename T>
void foo() {
    constexpr int x = -1;
    if constexpr (x >= 0){
        constexpr int y = 1 << dependent_value<T, x>::V;
    }
}

ЖИТЬ

Я не уверен, почему вы ожидаете, что ветка не будет проверена. Единственный раз, когда ветвь if "не проверена", - это когда она является частью шаблона, а не создана, согласно [stmt.if] p2:

Во время создания экземпляра включающего шаблонного объекта (раздел 17), если условие не зависит от значения после его создания, отвергнутое подзаполнение (если оно есть) не создается.

Кажется, ваш код не подходит для этой ситуации.