philnik added inline comments.
================
Comment at: clang/docs/LanguageExtensions.rst:1386
+Relaxed constexpr __cpp_constexpr C++14
C++11
+Designated initializers __cpp_designated_initializers C++20
C++03
+Attributes on enums __cpp_enumerator_attributes C++17
C++11
----------------
aaron.ballman wrote:
> This brings up a few questions for me: how should we handle C? For example,
> designated initializers also exist in C99 and are backported to C89? And how
> should we handle C features extended into C++ (or vice versa)?
>
> Should we have multiple tables? Should we try to put both languages into one
> table with different columns?
>
> (I'm not asking you to sign up to figure out the C extensions, just trying to
> get an idea for whether we want to change the layout of this table to account
> for that sort of thing.)
I think it would make sense to put C features that are back-ported into
previous standards also into this table (are there FTMs for C?). C into C++ or
vice versa should probably live somewhere else, since in these cases it would
also be interesting how things interact with other language features. Maybe
this is not as much of a problem for C++->C(?), but definitely for C->C++. e.g.
`__restrict` on member functions or VLAs with non-trivial classes. Essentially,
there is a lot more to say than "this also exists in previous standards".
================
Comment at: clang/docs/LanguageExtensions.rst:1387
+Designated initializers __cpp_designated_initializers C++20
C++03
+Attributes on enums __cpp_enumerator_attributes C++17
C++11
+Guaranteed copy elision __cpp_guaranteed_copy_elision C++17
C++03
----------------
aaron.ballman wrote:
> What are your thoughts on extensions enabled by a feature flag? e.g.,
> https://godbolt.org/z/ex9K5dzv6
I actually had no idea they existed (might be worth documenting :P)!
Specifically for this case: Is there any reason this is behind a feature flag?
I guess it's a non-conforming extension? If not, I'd say just make it an
enabled-by-default extension (it would be a really nice cleanup opportunity for
libc++). Anyways, we could add another column "flags required" for these cases.
Do you know how many of these kinds of flags there are?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D150321/new/
https://reviews.llvm.org/D150321
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
