Re: do { quit; } else { }

On 10/04/2025 01:20, Kaz Kylheku wrote:

On 2025-04-09, bart <bc@freeuk.com> wrote:

I'm not sure what your gripe is other than maybe I picked up on
something you got wrong. The discussion was about two struct types like
this:
>
     typedef struct tag1 {...} T1;
     typedef struct tag2 {...} T2;
>
and whether T1 and T2 were compatible or not. You said:
>
"and those types are not compatible, because the two struct tags are
different."
>
In this case the tags would be "tag1" and "tag2". I then said:
>
"I get an incompatible error (from the example you snipped) even when I
remove both struct tags."

 When you remove the tag from a struct definition, the implementation
behaves as if it were implementing a unique tag which is different
from any other such tag, and any tag that can possibly be written
using textual syntax.
 How did you implement tagless struct declarations in your compiler?
 

That means removing "tag1" and "tag2" so the example above looks like this:
>
     typedef struct {...} T1;
     typedef struct {...} T2;
>
Here, you can't say the struct tags are different, as they are not
visible!

 So if you close your eyes, two things that were different are now
no longer different, since they are invisible?
 The tag is a property of the type, not of printed type declaration.

Someone, not anyone but the all-knowing Tim, said: "and those types are not compatible, because the two struct tags are different."
Do you agree with that? Or is there something more to making two types be incompatible?
My examples included ones where tags /were/ different; tags which were identical (in nested scopes) and tags which were missing.
My view is that even if type discrimination was 100% dependent on tags, then it would be poor to rely on something which can be invisible in source code (either tags don't exist, or they appear identical).

A struct type has a tag. If the declaration doesn't show one,
that doesn't mean it doesn't have a tag.
 If a "Simulation" object has a "gravity" member, do you conclude
that a given simulation has no gravity, because the constructor
omitted specifying it?
    Simulation s = new Simulation(windSpeed = 35.7)

This is quite irrelevant, since 'gravity' will be defined somewhere in the source code, but you are talking about some internal attribute that may or may not be used by an implementation.

As I concluded, your assertion about compatibility being based on tags
being the same or not didn't seem right.)

 Or, you know, you could stop caring about what someone wrote in
comp.lang.c, be they right or wrong, and ... look it up?

Why don't you just tell me?
In my C compiler, each type has a unique index which is what is compared to see if two types are the same type. It has nothing to do with tags.
This C code:
     struct     {int x;};
     struct     {int x;};
     struct Tag {int x;};
     {struct Tag {int x;};}
Produces these 4 distinct types, with indices 23-26:
   23 struct (i32 x)
      Name: struct $T1
      Def:  03C24580 $T1.1          # .1 etc is a block scope index
   24 struct (i32 x)
      Name: struct $T2
      Def:  03C246C0 $T2.1
   25 struct (i32 x)
      Name: struct Tag
      Def:  03C247F0 Tag.1
   26 struct (i32 x)
      Name: struct Tag
      Def:  038D2910 Tag.2
The types without tags will have an internal tag supplied, since each user type is required to have an ST entry. But it is the 23/24/25/26 that is used in the type system to discriminate between them.