aaron.ballman added a comment. In D133289#4036529 <https://reviews.llvm.org/D133289#4036529>, @aaron.ballman wrote:
> I spoke with @to268 during office hours about the current status of the NB > comments for this feature in the C committee. For the moment, he's going to > pause work on this patch until the C committee weighs in on whether `auto` is > a type specifier or not. The committee meets the week of Jan 23, so we should > have a better understanding of direction by the week of Jan 30. If the C > committee turns `auto` into a type specifier, we may go back to the original > implementation of this feature which exposes the C++ feature in C (and add > diagnostics around the things that need to be constrained in C such as use in > a function signature). The minutes from last week's meeting aren't available yet, but I can give an update from my personal notes. Alex Gilding wrote a proposal to change the specification mechanisms away from "storage class specifier with no type specifier" and to an actual type specifier in WG14 N3076 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3076.pdf). WG14 briefly looked at the paper, but given how late in the cycle we are, we did not want to adopt new specification wording that is so drastically different from the existing wording. So we repaired the national body comments with WG14 N3079 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3079.htm) instead. > Does WG14 want something along the lines of N3076 in a future revision of the > standard? 10 (for)/0 (against)/7 (abstain) -- consensus So we now have sufficient support within WG14 for Clang to expose our C++ implementation of `auto` in C (with additional diagnostics for functionality C doesn't yet support like `auto` in function signatures) instead of implementing it from scratch as a weird storage class specifier/missing type specifier. However, we did make some other repairs to the feature so the current wording in the working draft (WG14 N3054) is not the latest. Specifically, we adopted US-122 and US-123 changes from WG14 N3079. WG14 is expecting to have another week of meetings to work on NB comments (week of Feb 13) and we are expecting to have a second round of NB comments. I think it's okay for us to restart work on this patch now that we have a direction, but we might want to hold off on landing the patch until after we have a better idea of the final form of the specification. If there are no comments about it in CD2, then we're fine, but it's possible for CD2 to make breaking changes to the feature, so it's mostly about being aware of that situation. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D133289/new/ https://reviews.llvm.org/D133289 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
