C++95: “#story Кина не будет: цирк в комитете по C++ 🤹 Как я писал, в C++23 п…”

#story

Кина не будет: цирк в комитете по C++ 🤹

Как я писал, в C++23 приняли аттрибут [[assume(expr)]]. Просматривая статус поддержки C++23 в Clang, я увидел что этот аттрибут пока не поддержан.

Я отправил патч на его поддержку - https://reviews.llvm.org/D144334

Это заняло мало времени и всего несколько строк в коде (не считая тестов и документации), потому что в Clang уже есть __builtin_assume, который сделан аналогично:

    case attr::Assume: {
      llvm::Value *ArgValue = EmitScalarExpr(cast<AssumeAttr>(A)->getCond());
      llvm::Function *FnAssume = CGM.getIntrinsic(llvm::Intrinsic::assume);
      Builder.CreateCall(FnAssume, ArgValue);
      break;
    }

В ревью пришло несколько человек и началась клоунада. Оказывается, что представители Clang и MSVC на встречах комитета по стандартизации заявляли, что отказываются реализовывать эту фичу по разным причинам. Причины понятны - плохо полагаться на не описанное в стандарте поведение компилятора (в своем посте я описывал опасности).

Часть переписки по патчу:

erichkeane:

So one thing to note here: I'm on the fence as to whether we want to implement this feature at all. As was discussed extensively during the EWG meetings on this: multiple implementers are against this attribute for a variety of reasons, and at least 1 other implementer has stated they might 'implementer veto' this. I think there is discussion to be had among the code owners here as to whether we even want this.

Izaron:

I don't quite understand how it works. The feature has been approved for C++2b, but it should have not been approved if there were concerns from implementers. <...> Could you please elaborate: if you decide to not implement this feature, you will kind of revoke the proposal or just deliberately do not support a part of C++2b in Clang?

erichkeane:

Just deliberately not support a part of C++2b. Implementers have veto'ed features in the past exactly that way.

aaron.ballman:

Agreed, (IMO) it should not have been approved given how many implementer concerns were expressed. But what goes into the standard is whatever gains consensus in the committee, so the committee occasionally runs the risk of voting in something that won't be implemented. We try to avoid it whenever possible, but it still happens with some regularity.

Вот так! Деды из комитета могут принимать любые изменения, которые Clang и/или GCC и/или MSVC никогда не реализуют, просто по большинству голосов. Комитет всегда умеет удивить.