Re: If you could change the C or C++ or Java syntax, what would you like different?



(Aside: I've been reading the standards documents so I am armed
(reloaded?) and dangerous). ;)

Seebs wrote:
On 2010-10-21, Keith Thompson <kst-u@xxxxxxx> wrote:
Seebs <usenet-nospam@xxxxxxxxx> writes:
Before it happens, "foo x;" is not a valid declaration, because foo
doesn't denote a type. After it happens, "foo x;" is a valid
declaration, because foo denotes a type. There was no type denoted
by "foo" previously.

But it's not a new type, and it wasn't created by the typedef.

I am not convinced. See next example.

An existing type changed from not being denoted by the name "foo" to
being denoted by the name "foo".

What existing type?

typedef struct { int x; } foo;

The above is a type name (re)definition of an anonymous(?) struct.


What is the "existing type"? What do you mean by "existing", anyway?
In what way did that type have existence prior to this line of code
executing?

Can you suggest a way in which I could then declare something else,
without using "typedef foo bar" or the equivalent, such that
(somethingelse *) and (foo *) are considered compatible types?

I'd say that they are two types, which happen to be the same. It's
a new thing, it just happens to be identical to an old thing.
Here's the thing.

I'd say that you're mangling the meaning of the word "two".

A name is not the thing it refers to.

No, but when we're talking about language, the name is more
interesting.

"size_t" is a type name, and "unsigned int" is a type name. They are
two different names for the same type. There are not two types here,
just one.

The thing you put in front of x to declare x is the name of a type,
but it's just as useful to say that it's the type of x.

The things in front of an identifier are declaration specifiers. One kind
of declaration specifier is a type specifier, the set of which includes,
e.g., 'int' and also typedef-name. Another kind of specifier is a
storage-class specifier, the set of which includes, e.g., 'extern' and
also 'typedef'.*

extern int x; // type of ident 'x' is 'extern int'
typedef int foo; // type of ident 'foo' is 'typedef int'
foo x; // type of 'x' is int

According to the rules specified in the standard, the type of ident 'x'
in the last example above should be 'foo', but according to examples in
the standard, the type of ident 'x' is 'int', which means that typedef
declarations are special from other declarations as far as I grok.

*"The typedef specifier is called a "storage-class specifier" for
syntactic convenience only".


I disagree. I don't think a type-name is part of the type; it's
just a name that refers to a type.

Types are descriptions of objects (e.g., data objects) or functions.
Types are a subdivision of a particular thing, e.g., "integer types". It
is probably proper to think in terms of "type specification" but not
proper to think in terms of "type name". It is probably proper to
synonymously use: "type", "type specification", "type description". It is
a stretch to say: "'int' is the name of a type", because 'int' *is* a
type. Things that can have names are: objects, functions, tags, members,
typedefs, labels, macros, macro parameters. Declarations introduce or
redeclare names into the translation unit. Declarations do not introduce
types.


I think the existence of pairs of types with identical storage and
representation, but which are considered distinct, suggests that
"typeness" has to do with something other than representation or
storage.

Yes, it has to do only with the description, which just so happens to
*be* the type.


For historical reasons, C in some cases allows you to have two types
which happen to be considered interchangeable, but I think they're
still
two types.

If the description is different ("synonymous" means "the same"), then
they are different.

Anyway, I think the whole thing is killed by the heading for 6.7. If
typedef is introduced under the heading "Type Definitions", then the
standard has clearly committed to the notion that typedef is defining
types.

Actually, no. I thought that too at first but see it differently now
unless I'm getting into the proverbial "analysis paralysis".


.


Quantcast