[cfe-dev] C vs. C++: Inconsistent type classifications

[argiris kirtzidis]

Doug Gregor wrote:
> There are several places where C and C++ have different definitions
> for the same type classification terms. For example, "integer types"
> in C include enumeration types, but "integer types" in C++ doesn't
> include enumeration types. On the other hand, "object types" in C
> doesn't include incomplete types, while "object types" in C++ does
> include incomplete types.
>
> This presents a dilemma for the Type class, which has methods like
> isIntegerType and isObjectType. It isn't clear whether these routines
> should follow the C semantics, the C++ semantics, the current language
> semantics, or whether we should decide on a case-by-case basis.
>
> The third option turns out to be a bad idea: I prototyped it with
> isIntegerType, making it follow the C semantics when we're in C and
> the C++ semantics when we're in C++. This is fine for the C-specific
> and C++-specific parts of the compiler, but it becomes very messy in
> the common subset of C and C++. Let's not go there.
>
> Personally, I favor following the C++ semantics, because I find the
> C++ classifications more natural ("integer" type doesn't scream
> "enumeration" for me, and whether or not we've seen a definition for a
> type shouldn't affect what kind of type it is), and of course, in the
> long run, the majority of the code in Clang is going to go toward
> supporting C++.
>   

How about having two methods when there are differences, e.g. 
isCIntegerType and isCXXIntegerType.
Having checks with C++ semantics called by C-parts will probably lead to 
confusion and subtle bugs.

-Argiris