Does C, as a language, need to allow its structs to have tags?

AIUI a fragment such as "struct A {....};" reserves no storage but
declares a template which can be used later, e.g. to declare a variable
as in

struct A var;

to declare a parameter as in

void f(struct A parm) {....}

to effect a cast as in

(struct A *) p

etc but in all such cases struct A is being used as a type. And there is
a more general feature for that in typedef.

So could C's struct tags be omitted from the language? If not, what does
a struct tag add? Is it something to do with forward declarations or
syntactic consistency with union tags, etc?

--
James Harris

On 06/06/2021 14:16, James Harris wrote:
> Does C, as a language, need to allow its structs to have tags?
>
> AIUI a fragment such as "struct A {....};" reserves no storage but
> declares a template which can be used later, e.g. to declare a variable
> as in
>
>   struct A var;
>
> to declare a parameter as in
>
>   void f(struct A parm) {....}
>
> to effect a cast as in
>
>   (struct A *) p
>
> etc but in all such cases struct A is being used as a type. And there is
> a more general feature for that in typedef.
>
> So could C's struct tags be omitted from the language? If not, what does
> a struct tag add? Is it something to do with forward declarations or
> syntactic consistency with union tags, etc?
>

Struct tags are not required if you have a typedef:

typedef struct { int a; int b; } A;

They are also not needed if you only refer to the struct once :

struct { int a; int b; } a;

But in general if you have two "struct" declarations, these define
different types - even if they contain the same members. So if you want
to use the type more than once, you need to give it a name - either
using a tag or by making it part of a typedef.

Forward declarations require a tag - there is no way to avoid that.
Beyond that, I think you can skip tags and stick to typedef if you prefer.

(Some people feel it is better to refer to the type as "struct A" rather
than a typedef "A", others prefer to use typdefs and avoid the "struct"
part.)

On Sunday, 6 June 2021 at 15:16:17 UTC+3, James Harris wrote:
> Does C, as a language, need to allow its structs to have tags?
>
> AIUI a fragment such as "struct A {....};" reserves no storage but
> declares a template which can be used later, e.g. to declare a variable
> as in
>
> struct A var;
>
> to declare a parameter as in
>
> void f(struct A parm) {....}
>
> to effect a cast as in
>
> (struct A *) p
>
> etc but in all such cases struct A is being used as a type. And there is
> a more general feature for that in typedef.
>
> So could C's struct tags be omitted from the language? If not, what does
> a struct tag add? Is it something to do with forward declarations or
> syntactic consistency with union tags, etc?

Not from C language. C language removes only features that no one
uses and even those very slowly. The "struct A" will be there forever as
it is quite popular. But from your code go ahead, David Brown
explained how.

On 06/06/2021 13:16, James Harris wrote:
> Does C, as a language, need to allow its structs to have tags?
>
> AIUI a fragment such as "struct A {....};" reserves no storage but
> declares a template which can be used later, e.g. to declare a variable
> as in
>
>  struct A var;
>
> to declare a parameter as in
>
>  void f(struct A parm) {....}
>
> to effect a cast as in
>
>  (struct A *) p
>
> etc but in all such cases struct A is being used as a type. And there is
> a more general feature for that in typedef.
>
> So could C's struct tags be omitted from the language? If not, what does
> a struct tag add? Is it something to do with forward declarations or
> syntactic consistency with union tags, etc?
>
>

They add nothing at all to the language. Other languages don't need
them. Even C++ I think is moving away from them.

It's just another quirk among many (you probably know that tags have
their own namespace too).

However, as C works at the minute, tags are needed for self-referential
structs, or with cyclic references. This won't work, even if you try and
have a forward declaration for Node:

typedef struct {
int data;
Node* next;
} Node;

You have to use:

typedef struct Nodetag{
int data;
struct Nodetag* next;
} Node;

Of course, as a long-standing feature of C, many will claim it is
invaluable. For example that using:

struct Nodetag x;

is clearer than:

Node x;

because you know that you're dealing with a struct. My view is that a
feature that allows:

struct Nodetag Nodetag;

is not one you'd want one to emulate.

On 2021-06-06, James Harris <james.harris.1@gmail.com> wrote:
> etc but in all such cases struct A is being used as a type. And there is
> a more general feature for that in typedef.

typedef is general, but a general what?

It's purely a type aliasing mechanism for giving names to existing
types. It doesn't define new types.

> So could C's struct tags be omitted from the language? If not, what does
> a struct tag add? Is it something to do with forward declarations or
> syntactic consistency with union tags, etc?

The tag is essential in the C design for self-referential
structures:

struct node {
struct node *next;
void *datum;
};

typedef cannot solve this because

typedef struct {
node *next; // error: typedef does not exist yet!
void *datum;
} node;

The struct specifier is what introduces a type; typedef just introduces
the name "node" into the scope which refers to that type.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 2021-06-06, Bart <bc@freeuk.com> wrote:
> You have to use:
>
> typedef struct Nodetag{

There is no requirement that the tag and type name must be distinct
since they are in separate namespaces.

> int data;
> struct Nodetag* next;
> } Node;

It will work wit a forward declaration too, but that of course
still requires the tag appearing in two places:

typedef struct Nodetag Node;

struct Nodetag {
Nodetag *next;
};

> because you know that you're dealing with a struct. My view is that a
> feature that allows:
>
> struct Nodetag Nodetag;
>
> is not one you'd want one to emulate.

On the contrary, type names should be in a separate namespace, so that
an object of type foo can naturally be named foo when you need it:

node = new node;
other_node = new node;

Only crap languages reduce everything to one namespace.

C does not escape this disparagement. Though it provides that
struct/enum tag namespace, it's for those kinds of types only, and you
have to reference it explicitly.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 06/06/2021 15:51, Kaz Kylheku wrote:
> On 2021-06-06, James Harris <james.harris.1@gmail.com> wrote:
>> etc but in all such cases struct A is being used as a type. And there is
>> a more general feature for that in typedef.
>
> typedef is general, but a general what?
>
> It's purely a type aliasing mechanism for giving names to existing
> types. It doesn't define new types.
>
>> So could C's struct tags be omitted from the language? If not, what does
>> a struct tag add? Is it something to do with forward declarations or
>> syntactic consistency with union tags, etc?
>
> The tag is essential in the C design for self-referential
> structures:
>
> struct node {
> struct node *next;
> void *datum;
> };
>
> typedef cannot solve this because
>
> typedef struct {
> node *next; // error: typedef does not exist yet!
> void *datum;
> } node;
>
> The struct specifier is what introduces a type; typedef just introduces
> the name "node" into the scope which refers to that type.

It's only essential because C has decided that's how it has to work.

Your example works with C++; how does that manage it?

C could have done it with a forward declaration of 'node', but:

typedef node;

is not valid; you need to give a type, and that type then counts as
either a separate or duplicate struct to the one defined later. Or you
use a tag for that forward, empty struct declaration, so you're back to
square one.

It's just fortuitous that the tag is placed just before {...} instead of
just after, otherwise you'd have the same problem with tags.

A minor tweak of syntax, such as:

typedef newtype = oldtype; // with oldtype name-less

instead of:

typedef oldtype newtype; // with oldtype/newtype wrapped around
// each other for complex types

would have done it.

On 06/06/2021 16:05, Kaz Kylheku wrote:
> On 2021-06-06, Bart <bc@freeuk.com> wrote:
>> You have to use:
>>
>> typedef struct Nodetag{
>
>
> There is no requirement that the tag and type name must be distinct
> since they are in separate namespaces.
>
>> int data;
>> struct Nodetag* next;
>> } Node;
>
> It will work wit a forward declaration too, but that of course
> still requires the tag appearing in two places:
>
> typedef struct Nodetag Node;
>
> struct Nodetag {
> Nodetag *next;
> };
>
>
>> because you know that you're dealing with a struct. My view is that a
>> feature that allows:
>>
>> struct Nodetag Nodetag;
>>
>> is not one you'd want one to emulate.
>
> On the contrary, type names should be in a separate namespace, so that
> an object of type foo can naturally be named foo when you need it:

Why would you want that? Case-sensitive languages already allow that
anyway if you're really stuck for inventing meaningful new identifiers.

Foo foo;

> node = new node;
> other_node = new node;

It took me a while to figure out what this is supposed to mean.

So 'node' following 'new' is a type; but the other node is a variable
name? What about:

node node;

> Only crap languages reduce everything to one namespace.

Namespaces are used where they are genuinely useful, for example to
disambiguate A.F from B.F. It's not so you can have F meaning two or
more different things within the same scope. This is an example from C
(one of 8 case variations of the three As):

A:; struct A A; goto A;

Really handy when half the keys don't work on your keyboard!

On 06/06/2021 16:05, Bart wrote:
> On 06/06/2021 15:51, Kaz Kylheku wrote:

....

>> The tag is essential in the C design for self-referential
>> structures:

Agreed with those who have mentioned that. I am not sure whether C still
needs to prohibit forward references. They were once needed for
single-pass compilation, I would think, but that era is long past.

> It's just fortuitous that the tag is placed just before {...} instead of
> just after, otherwise you'd have the same problem with tags.

Far from fortuitous it's more likely to be good design. With

struct A {....} B;

isn't it true that either A or B can be omitted, and that A will be the
struct tag and B will be an identifier which is being declared as of the
specified struct type? And it fits with C's ordering of

type identfier

That's a really quite subtle and consistent design feature, ISTM.

>
> A minor tweak of syntax, such as:
>
>   typedef newtype = oldtype;   // with oldtype name-less
>
> instead of:
>
>   typedef oldtype newtype;     // with oldtype/newtype wrapped around
>                                // each other for complex types
>
> would have done it.

Yes, I prefer your 'tweaked' syntax for a programming language (though
am not suggesting it for C), just without the semicolon, as in

typedef newtypename = oldtypespec

--
James Harris

On 6/6/2021 5:05 PM, Kaz Kylheku wrote:
> On 2021-06-06, Bart <bc@freeuk.com> wrote:
>> You have to use:
>>
>> typedef struct Nodetag{
>
>
> There is no requirement that the tag and type name must be distinct
> since they are in separate namespaces.
>
>> int data;
>> struct Nodetag* next;
>> } Node;
>
> It will work wit a forward declaration too, but that of course
> still requires the tag appearing in two places:
>
> typedef struct Nodetag Node;
>
> struct Nodetag {
> Nodetag *next; // error: unknown type name ‘Nodetag’
> };
>
>

typedef struct Nodetag Node;

struct Nodetag {
int data;
Node *next;
};

On 6/6/21 8:16 AM, James Harris wrote:
> Does C, as a language, need to allow its structs to have tags?
>
> AIUI a fragment such as "struct A {....};" reserves no storage but
> declares a template which can be used later, e.g. to declare a variable
> as in
>
> struct A var;
>
> to declare a parameter as in
>
> void f(struct A parm) {....}
>
> to effect a cast as in
>
> (struct A *) p
>
> etc but in all such cases struct A is being used as a type. And there is
> a more general feature for that in typedef.
>
> So could C's struct tags be omitted from the language? If not, what does
> a struct tag add? Is it something to do with forward declarations or
> syntactic consistency with union tags, etc?

C++ dropped the requirement for tags, so it's clearly not necessary.
Except when hidden by the use of a typedef, C's rule guarantees that
every specification of a struct type includes the "struct" keyword.
Because of that rule, struct tags have their own separate name space,
which allows you to use the same identifier for a struct type and for a
given object of that type. That's not possible in C++, where they are in
the same name space. Note: a "name space" is a concept that exists in
both of those languages, though it's less important in C++. A "name
space" is not directly related to the C++ namespace keyword.
Strougstrop obviously thought that the C++ rules were an improvement. C
is more constrained than C++ by the need to maintain backwards
compatibility, which would be broken by adoption of the C++ rules.

On 6/6/21 8:16 AM, James Harris wrote:
> Does C, as a language, need to allow its structs to have tags?
>
> AIUI a fragment such as "struct A {....};" reserves no storage but
> declares a template which can be used later, e.g. to declare a variable
> as in
>
>   struct A var;
>
> to declare a parameter as in
>
>   void f(struct A parm) {....}
>
> to effect a cast as in
>
>   (struct A *) p
>
> etc but in all such cases struct A is being used as a type. And there is
> a more general feature for that in typedef.
>
> So could C's struct tags be omitted from the language? If not, what does
> a struct tag add? Is it something to do with forward declarations or
> syntactic consistency with union tags, etc?
>
>

The biggest need is for referencing a struct whose definition hasn't
been given, especially as a pointer type.

You can say 'struct A' to reference that type without ever having seen
the actual definition of what that structure looks like.

You can NOT do this with a typedef. You CAN say
typedef struct A Astruct; to make Astruct a typedef for that unknown
struct type, but even that requires the struct tag to be specified, so
it can possible be linked later when the struct is actually defined.

Except by using this sort of tag, there is no way in C to say that a
name is to some type that may be defined later.

I suppose C could be extended to allow a statement like typedef A; to
define that A was a type, that later might get connected to some defined
type. This would allow you to define pointers to that type.

On 06/06/2021 18:58, Manfred wrote:
> On 6/6/2021 5:05 PM, Kaz Kylheku wrote:
>> On 2021-06-06, Bart <bc@freeuk.com> wrote:
>>> You have to use:
>>>
>>>     typedef struct Nodetag{
>>
>>
>> There is no requirement that the tag and type name must be distinct
>> since they are in separate namespaces.
>>
>>>       int data;
>>>       struct Nodetag* next;
>>>     } Node;
>>
>> It will work wit a forward declaration too, but that of course
>> still requires the tag appearing in two places:
>>
>>    typedef struct Nodetag Node;
>>
>>    struct Nodetag {
>>      Nodetag *next; //  error: unknown type name ‘Nodetag’
>>    };
>>
>>
>
> typedef struct Nodetag Node;
>
> struct Nodetag {
>   int data;
>   Node *next;
> };

Or even:

typedef struct Node Node;

struct Node {
int data;
Node *next;
};

There's no need for an extra name here.

On 06/06/2021 20:12, David Brown wrote:
> On 06/06/2021 18:58, Manfred wrote:
>> On 6/6/2021 5:05 PM, Kaz Kylheku wrote:

>>>    typedef struct Nodetag Node;
>>>
>>>    struct Nodetag {
>>>      Nodetag *next; //  error: unknown type name ‘Nodetag’
>>>    };
>>>
>>>
>>
>> typedef struct Nodetag Node;
>>
>> struct Nodetag {
>>   int data;
>>   Node *next;
>> };
>
>
> Or even:
>
> typedef struct Node Node;
>
> struct Node {
> int data;
> Node *next;
> };
>
> There's no need for an extra name here.

Unless you want to avoid any confusion. Since you can come across this:

Node* A;
struct Node* B;

Does one of those lines have a 'struct' missing, or does the other have
a 'struct' that shouldn't be there?

The eye picks up such inconsistencies; it creates a distraction.

Allowing two ways of denoting the same user-type is also sloppy.

On 06/06/2021 21:02, Bart wrote:
> On 06/06/2021 20:12, David Brown wrote:
>> On 06/06/2021 18:58, Manfred wrote:
>>> On 6/6/2021 5:05 PM, Kaz Kylheku wrote:
>
>
>>>>     typedef struct Nodetag Node;
>>>>
>>>>     struct Nodetag {
>>>>       Nodetag *next; //  error: unknown type name ‘Nodetag’
>>>>     };
>>>>
>>>>
>>>
>>> typedef struct Nodetag Node;
>>>
>>> struct Nodetag {
>>>    int data;
>>>    Node *next;
>>> };
>>
>>
>> Or even:
>>
>> typedef struct Node Node;
>>
>> struct Node {
>>    int data;
>>    Node *next;
>> };
>>
>> There's no need for an extra name here.
>
> Unless you want to avoid any confusion. Since you can come across this:
>
> Node* A;
> struct Node* B;
>
> Does one of those lines have a 'struct' missing, or does the other have
> a 'struct' that shouldn't be there?
>
> The eye picks up such inconsistencies; it creates a distraction.
>
> Allowing two ways of denoting the same user-type is also sloppy.

That's why the "_t" suffix in "typedef struct foo foo_t" is popular.

Personally, I'm happy to loose the typedef and say struct foo when
that's what I mean. It's not that much extra typing.

Bart <bc@freeuk.com> writes:
> On 06/06/2021 13:16, James Harris wrote:
>> Does C, as a language, need to allow its structs to have tags?
>>
>> AIUI a fragment such as "struct A {....};" reserves no storage but
>> declares a template which can be used later, e.g. to declare a
>> variable as in
>>
>>  struct A var;
>>
>> to declare a parameter as in
>>
>>  void f(struct A parm) {....}
>>
>> to effect a cast as in
>>
>>  (struct A *) p
>>
>> etc but in all such cases struct A is being used as a type. And
>> there is a more general feature for that in typedef.
>>
>> So could C's struct tags be omitted from the language? If not, what
>> does a struct tag add? Is it something to do with forward
>> declarations or syntactic consistency with union tags, etc?
>
> They add nothing at all to the language. Other languages don't need
> them. Even C++ I think is moving away from them.

No, it isn't.

In C, you can define a structure type as
struct foo { /* members /* };

where "foo" is the tag. The name of the resulting type is "struct foo".
You can optionally add a typedef if you prefer to refer to it as "foo"

In C++, the same type, defined with the same syntax, can be referred to
either as "struct foo" or as "foo"; the latter is more common. The
identifier "foo" is still the struct tag. C++ has worked this way for
decades; it's not "moving away" from anything.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:
> On 06/06/2021 20:12, David Brown wrote:
>> On 06/06/2021 18:58, Manfred wrote:
>>> On 6/6/2021 5:05 PM, Kaz Kylheku wrote:
>>>>    typedef struct Nodetag Node;
>>>>
>>>>    struct Nodetag {
>>>>      Nodetag *next; //  error: unknown type name ‘Nodetag’
>>>>    };
>>>>
>>>>
>>>
>>> typedef struct Nodetag Node;
>>>
>>> struct Nodetag {
>>>   int data;
>>>   Node *next;
>>> };
>>
>>
>> Or even:
>>
>> typedef struct Node Node;
>>
>> struct Node {
>> int data;
>> Node *next;
>> };
>>
>> There's no need for an extra name here.
>
> Unless you want to avoid any confusion. Since you can come across this:
>
> Node* A;
> struct Node* B;
>
> Does one of those lines have a 'struct' missing, or does the other
> have a 'struct' that shouldn't be there?
>
> The eye picks up such inconsistencies; it creates a distraction.
>
> Allowing two ways of denoting the same user-type is also sloppy.

Which is a great argument for not bothering with the typedef:

struct Node {
int data;
struct Node *next;
};

struct Node obj;
struct Node *ptr;
// ...

(Bart will argue that having to type "struct" again is a heavy burden.
I will not respond.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

On 06/06/2021 23:13, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 06/06/2021 20:12, David Brown wrote:
>>> On 06/06/2021 18:58, Manfred wrote:
>>>> On 6/6/2021 5:05 PM, Kaz Kylheku wrote:
>>>>>    typedef struct Nodetag Node;
>>>>>
>>>>>    struct Nodetag {
>>>>>      Nodetag *next; //  error: unknown type name ‘Nodetag’
>>>>>    };
>>>>>
>>>>>
>>>>
>>>> typedef struct Nodetag Node;
>>>>
>>>> struct Nodetag {
>>>>   int data;
>>>>   Node *next;
>>>> };
>>>
>>>
>>> Or even:
>>>
>>> typedef struct Node Node;
>>>
>>> struct Node {
>>> int data;
>>> Node *next;
>>> };
>>>
>>> There's no need for an extra name here.
>>
>> Unless you want to avoid any confusion. Since you can come across this:
>>
>> Node* A;
>> struct Node* B;
>>
>> Does one of those lines have a 'struct' missing, or does the other
>> have a 'struct' that shouldn't be there?
>>
>> The eye picks up such inconsistencies; it creates a distraction.
>>
>> Allowing two ways of denoting the same user-type is also sloppy.
>
> Which is a great argument for not bothering with the typedef:
>
> struct Node {
> int data;
> struct Node *next;
> };
>
> struct Node obj;
> struct Node *ptr;
> // ...
>
> (Bart will argue that having to type "struct" again is a heavy burden.
> I will not respond.)
>

There is NO argument. Every other language including C++ sees separate
tag names as pointless. C++ can't completely get rid of them, so still
allows 'struct tag{}' or 'struct tag x' for compatibility with C code,
although 'struct tag{}' here creates a typedef 'tag' too.

C++ actually allows this:

typedef struct T {int x,y;} U;

so that you can use T, struct T or U (but not struct U). So C
compatibility has given it /three/ ways of denoting the same user-type!

I declare such a struct like this (in one language):

type T = struct (int x,y)

It declares exactly one user type, denoted always as just 'T'.

Bart <bc@freeuk.com> writes:
[...]
> There is NO argument. Every other language including C++ sees separate
> tag names as pointless. C++ can't completely get rid of them, so still
> allows 'struct tag{}' or 'struct tag x' for compatibility with C code,
> although 'struct tag{}' here creates a typedef 'tag' too.
[...]

No, that's not a typedef. It's just the name of the type. C++ does
have typedefs, but as in C they require the "typedef" keyword.

In C, you can write "typedef struct foo { ... } foo;". Then "foo" is a
typedef name, and an alias for the type that is also named "struct foo".

In C++, you can write "struct foo { ... };", and "struct foo" and
"foo" are both names for the type. Neither of them is a typedef.
The name "foo" acts much like the typedef name in C. (There might
be subtle differences; I'm not sure.)

And something I just noticed: C++ doesn't use the term "tag". "foo" is
a "class name".

The distinction is not deeply significant. I'm just like to get the
terminology right.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

On 06/06/2021 22:02, Bart wrote:
> On 06/06/2021 20:12, David Brown wrote:
>> On 06/06/2021 18:58, Manfred wrote:
>>> On 6/6/2021 5:05 PM, Kaz Kylheku wrote:
>
>
>>>>     typedef struct Nodetag Node;
>>>>
>>>>     struct Nodetag {
>>>>       Nodetag *next; //  error: unknown type name ‘Nodetag’
>>>>     };
>>>>
>>>>
>>>
>>> typedef struct Nodetag Node;
>>>
>>> struct Nodetag {
>>>    int data;
>>>    Node *next;
>>> };
>>
>>
>> Or even:
>>
>> typedef struct Node Node;
>>
>> struct Node {
>>    int data;
>>    Node *next;
>> };
>>
>> There's no need for an extra name here.
>
> Unless you want to avoid any confusion. Since you can come across this:
>
> Node* A;
> struct Node* B;
>
> Does one of those lines have a 'struct' missing, or does the other have
> a 'struct' that shouldn't be there?
>
> The eye picks up such inconsistencies; it creates a distraction.
>
> Allowing two ways of denoting the same user-type is also sloppy.
>

What you call "sloppy", others might call "flexible". You are, IIRC, a
fan of case-insensitive languages. Are they sloppy for letting you
write "foo" and "Foo" to mean the same thing? Or are you just engaging
in your favourite hobby - taking something that other people see as a
convenient way to write clearer code and using it for yet another
meaningless rant against C?

I agree that it is good to be consistent when you write your code, and I
would expect a programmer to choose either "struct Node" /or/ "Node",
and use it consistently. Generally, you'd only find the typedef at all
if the programmer intends to use "Node" consistently.

So there is no confusion that I can see.

(On the other hand, I think code like "struct Node Node;" is a lot more
likely to cause confusion.)

On 07/06/2021 07:52, David Brown wrote:
> On 06/06/2021 22:02, Bart wrote:

>> Unless you want to avoid any confusion. Since you can come across this:
>>
>> Node* A;
>> struct Node* B;
>>
>> Does one of those lines have a 'struct' missing, or does the other have
>> a 'struct' that shouldn't be there?
>>
>> The eye picks up such inconsistencies; it creates a distraction.
>>
>> Allowing two ways of denoting the same user-type is also sloppy.
>>
>
> What you call "sloppy", others might call "flexible". You are, IIRC, a
> fan of case-insensitive languages. Are they sloppy for letting you
> write "foo" and "Foo" to mean the same thing?

You mean in the same way that "bart", "Bart" or "BART" all refer to me?

Or the fact that if I say them out loud, they all sound identical too?

> Or are you just engaging
> in your favourite hobby - taking something that other people see as a
> convenient way to write clearer code and using it for yet another
> meaningless rant against C?

No. For me case sensitivity means code that ISN'T clearer because people
exploit that subtle difference in case between otherwise identical
names: to use them for different purposes not just within the same
scope, but across a program, where you have to keep doing a double-take.

Here are some wonderful examples from sqlite3.c:

Action action
affinity Affinity
B b
bIn bin
BusyHandler busyHandler
Clsid clsid CLSID
DbPage dbpage
debuginfo DebugInfo
dwContextHelpId dwContextHelpID
dwFlags dwflags
Edx eDx
errmsg errMsg
hwndActive hWndActive
message Message MESSAGE
nExt next Next
szPMA szPma
WalIndexHdr walIndexHdr

> I agree that it is good to be consistent when you write your code, and I
> would expect a programmer to choose either "struct Node" /or/ "Node",
> and use it consistently. Generally, you'd only find the typedef at all
> if the programmer intends to use "Node" consistently.

My manually written C code only ever defines structs as part of a
typedef. And only uses tags when necessary to define the struct. It is
then subsequently referred to by the typedef name.

My automatically generated C code does the opposite; never uses typedefs
for structs (because there, who cares?).

But in any other language, we just wouldn't be discussing this at all.
You create a new type, be it a struct or anything else, and it's called
T. End of story.

On 07/06/2021 12:06, Bart wrote:
> On 07/06/2021 07:52, David Brown wrote:
>> On 06/06/2021 22:02, Bart wrote:
>
>>> Unless you want to avoid any confusion. Since you can come across this:
>>>
>>> Node* A;
>>> struct Node* B;
>>>
>>> Does one of those lines have a 'struct' missing, or does the other have
>>> a 'struct' that shouldn't be there?
>>>
>>> The eye picks up such inconsistencies; it creates a distraction.
>>>
>>> Allowing two ways of denoting the same user-type is also sloppy.
>>>
>>
>> What you call "sloppy", others might call "flexible".  You are, IIRC, a
>> fan of case-insensitive languages.  Are they sloppy for letting you
>> write "foo" and "Foo" to mean the same thing?
>
> You mean in the same way that "bart", "Bart" or "BART" all refer to me?
>
> Or the fact that if I say them out loud, they all sound identical too?

So you are happy with multiple ways of writing "bart" or "BART" that
look very different, and would immediately be viewed as different
identifiers and therefore different meanings to people familiar with
case-sensitive programming languages. Yet you would be upset with two
versions of writing the same type in C that are really quite obvious to
C programmers - and where any mistakes (in real code) would be caught by
the compiler.

>
>> Or are you just engaging
>> in your favourite hobby - taking something that other people see as a
>> convenient way to write clearer code and using it for yet another
>> meaningless rant against C?
>
> No. For me case sensitivity means code that ISN'T clearer because people
> exploit that subtle difference in case between otherwise identical
> names: to use them for different purposes not just within the same
> scope, but across a program, where you have to keep doing a double-take.
>

Ah, it's the old "some people write code I didn't like, therefore the
language is bad" argument. You do like to take your own personal
opinion and think of it as global rules that should apply to everyone.
And you do like to take the worst (in your not so humble opinion)
examples and assume all code is written that way.

On 07/06/2021 12:25, David Brown wrote:
> On 07/06/2021 12:06, Bart wrote:

>> You mean in the same way that "bart", "Bart" or "BART" all refer to me?
>>
>> Or the fact that if I say them out loud, they all sound identical too?
>
> So you are happy with multiple ways of writing "bart" or "BART" that
> look very different, and would immediately be viewed as different
> identifiers and therefore different meanings to people familiar with
> case-sensitive programming languages. Yet you would be upset with two
> versions of writing the same type in C that are really quite obvious to
> C programmers - and where any mistakes (in real code) would be caught by
> the compiler.

The complaint is really about case-sensitivity in general, across
languages, file systems, OS command lines and, worst because YOU CAN'T
SEE WHAT YOU'RE TYPING, in passwords.

It is just an almighty pain. Fortunately for the most important
situations, common sense prevails and case-insensitivity is used.
(User-names, the first parts of web-addresses, emails and so on. Google
searches too!)

> Ah, it's the old "some people write code I didn't like, therefore the
> language is bad" argument. You do like to take your own personal
> opinion and think of it as global rules that should apply to everyone.
> And you do like to take the worst (in your not so humble opinion)
> examples and assume all code is written that way.

So, you don't take the same advantage of being able to use Foo and foo?

If that case, why do you need a case-sensitive language?

On Sunday, June 6, 2021 at 10:28:10 AM UTC-3, David Brown wrote:
[...]
> But in general if you have two "struct" declarations, these define
> different types - even if they contain the same members. So if you want
> to use the type more than once, you need to give it a name - either
> using a tag or by making it part of a typedef.

In some cases creating a name just make the code more complex.

I wish I could create template structs using macros.

#define vector(T) { T * data; int size, capacity; }

void F(struct vector(Card) * v);

this convention has more information associated than a typedef using
plural name for instance.

void F(struct Cards * v);

Similar of "struct Card cards[] " it brings the information about
the characteristics of the type.

Imagine in C if each time we need array of something
we have to assign a name to it.

int a[10]; //error you need to create a name for it first.

or each compound literal had to have a name...

C also doesn't have unnamed functions (like C++ lambdas) and
sometimes the name is artificially created and used in just one place like
callbacks.

On Monday, 7 June 2021 at 13:00:30 UTC+1, Bart wrote:
>
> So, you don't take the same advantage of being able to use Foo and foo?
>
> If that case, why do you need a case-sensitive language?
>
If the language is case-insensitive, you don't want the same identifier to
appear in the source in different cases. That confuses anyone who doesn't
know that the language is case insensitive, or who doesn't know that the
programmer who wrote the code knows that the language is case
insensitive, or who hasn't been told why such an odd practice is followed
(there might be reasons, such as attaching metadata to an identifier).

So in fact what you want is not a case insensitive language, but a language
which disallows identifiers which are identical except in case. Alternatively
a language which enforces rules such as "local variables must be lower case,
functions must start with an uppercase letter".

There are good arguments against allowing C's free for all. Virtually every coding
standard is more restrictive than C in the identifiers that it allows. However
backwards compatibility is all.