In other words, wchar_t is *not* a true type on its own.
Yes, I believe it is; thus the phrase "distinct type".
Consider a C implementation in which int and long have the same size,
signedness, and alignment requirements (such implementations are very
common). Implicit conversions mostly mask the fact that they're
distinct types, but the following program is still illegal (and would
be legal if they weren't distinct):
int main(void)
{
int *ip = 0;
long *lp = 0;
ip = lp;
return 0;
}
I believe the same is true for wchar_t and its "underlying type" (or,
more topically, it would be if the C standard had adopted C++'s
definition of wchar_t).
There are good uses for both flavours of typedef. Having "typedef" and
"typealias" would have been the right thing.
Agreed. As it is, though, "typedef" already creates an alias, and
changing that could break too much code; if we wanted to add this in a
future standard, we'd need a different keyword that creates a distinct
type.
How about "static typedef"?
}
[snip]
But if they don't match, the compiler *must* generate a diagnostic, so
where is the problem?
The problem is that it's non-portable code for which a compiler can't
easily generate a warning.
If I use a long argument with a "%d" printf format, a sufficiently
friendly compiler will warn me about it, even if int and long happen
to have the same characteristics. In the above example, it can't
reasonably issue a similar warning, since size_t and unsigned long
really are the same type on the platform in question. I suppose a
more aggressively friendly compiler could issue a warning anyway, but
there's no good way for the compiler to tell whether a given typedef
is meant to create a logically distinct type or just an alias.
The problem is caught as soon as it becomes a problem ;-)
If the code is unintentionally non-portable, I'd consider that an
immediate problem; I'd much rather fix it *before* I try to port the
code.
Adding a *new* keyword with your preferred semantics is still doable.
And changing things like size_t from their current status of type alias
to the status of "new type" shouldn't hurt existing *correct* code, as
long as the new type inherits all the properties of the underlying type.
I agree on the first point, but making size_t a distinct type could
make some existing correct (but non-portable) code illegal; I provided
an example above. I'm tempted to suggest that it's worth it.
