aaron.ballman added a comment. In D144334#4142462 <https://reviews.llvm.org/D144334#4142462>, @Izaron wrote:
> In D144334#4141646 <https://reviews.llvm.org/D144334#4141646>, @erichkeane > wrote: > >> 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 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. 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. > But it seems like not the case with the `assume` attribute. 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? To me, it's not clear whether we will or won't implement this particular attribute at the moment. Because Clang aims for compatibility with both GCC and MSVC, I'd like Clang to be the *last* to implement this attribute so we know exactly what we're signing up for in terms of compatibility requirements. We were bitten by `no_unique_address` and it's sporadic adoption and we do not want to get into the same situation with `assumes` because (as with `no_unique_address`) this attribute *cannot be ignored* (it can trigger template instantiations and other things that impact ABI, so a correct program with the attribute might not remain correct without the attribute). So that's not a "no, we'll never do it!" kind of situation so much as a "we're proceeding with extreme caution" situation. If every other C++ implementation supports this attribute, I see no reason why Clang wouldn't as well. But if either MSVC or GCC elect not to implement this attribute, we should understand why and decide our implementation strategy accordingly. In terms of C++2b, we (the Clang community) have no more chances to change things. A national body comment was filed to consider removing the feature from C++2b or altering it to be acceptable to implementers with concerns and WG21 rejected the comment, so about the only other option left is for companies who are members of a WG21 national body to vote NO on the C++2b DIS. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D144334/new/ https://reviews.llvm.org/D144334 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
