aaron.ballman added a comment.
In https://reviews.llvm.org/D52339#1242202, @erik.pilkington wrote:
> From the last line in the paper, it seems that C++ compatibility is a goal of
> the paper (or at least a consideration). We should probably think about this
> if/when the final wording gets accepted though.
Agreed. WG14's charter explicitly prefers compatibility with C++ when possible.
The part that I wasn't quite sure on were the type constraints in the proposal.
C++ allows any integral type and ignores cv qualifiers, but the proposal lists
specific types and doesn't discuss qualifiers. By my reading, this is code
allowed in C++ but prohibited in the proposed wording:
enum E : const int32_t {
One
};
(Because the type is int32_t and is cv-qualified.) However, it's possible
that's an oversight rather than an intentional design. I'll bring it up with
Clive to see, but perhaps we can spot other divergences and can provide him
with a list of concerns on the implementation side.
================
Comment at: clang/include/clang/Basic/Features.def:233
EXTENSION(cxx_variadic_templates, LangOpts.CPlusPlus)
+EXTENSION(cxx_fixed_enum, true)
// C++14 features supported by other languages as extensions.
----------------
erik.pilkington wrote:
> aaron.ballman wrote:
> > Are we sure we want to make this decision for things like OpenCL, Cuda, etc?
> I can't think of any reason why not, seems there are a handful of other
> EXTENSION(*, true) features. Do you have a preference?
I think we should probably ask folks from the projects to see if they're okay
with the extension or not, but I'd guess this won't be contentious.
Repository:
rC Clang
https://reviews.llvm.org/D52339
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
