<p>Some languages have a concept of classes separately than structs. In C++ the only difference is whether the members are public or private by default. This seems redundant. Why have a separate <code>class</code> keyword for such a minor and trivial difference? In Swift the difference is whether they are reference types or value types.</p>
<p>Is there an advantage to include both in cases where the difference is so minor for example in C++? How else does or could <code>class</code> behave differently than a <code>struct</code> in other languages that would warrant having them separately?</p>

<data-structures><classes>
Distinguishing classes from structures
CC BY-SA 4.0
2023-06-30T02:21:01.713Z
There are almost unlimited ways that classes and structs "could" behave differently, but most of them wouldn't be useful. Perhaps it would be better if the question asked about what differences exist between classes and structs in other languages which have both.
kaya3
CC BY-SA 4.0
2023-06-30T02:28:09.010Z
@kaya3-supportthestrike The scope of the question is comparable to the scope of syntax questions - in which there are almost unlimited syntaxes possible.
CPlus
CC BY-SA 4.0
2023-06-30T02:28:18.713Z
I think it seems kind of weird to first come up with a feature (having both `class` and `struct`, with a distinction), then try to retroactively find a reason to have that feature.
rydwolf
CC BY-SA 4.0
2023-06-30T02:29:36.413Z
@RydwolfPrograms Do you think I should change this to a *'Why would you have `class` and `struct` both if they're so similar?'*
CPlus
CC BY-SA 4.0
2023-06-30T03:08:15.543Z
Ultimately, `class` and `struct` are two arbitrary keywords you can have in a programming language. They don’t universally refer to any well-defined semantic concept, so this question is ill-defined. Pedantically, the answer to “could `class` behave different from `struct`?” is “yes, because they can behave absolutely however the language designer decides they should behave.”
Alexis King
CC BY-SA 4.0
2023-06-30T07:30:49.393Z
The answers to this question seem to demostrate it is valuable.
Bruce Adams
CC BY-SA 4.0
2023-06-30T15:37:02.767Z
@BruceAdams I agree, I originally voted to close and then to reopen because while the focus of the question is weird, in some other (non-C++) languages classes and structures are very different beasts and defining what exactly is a class or a structure could be very interesting.
kouta-kun
<p>In many situations, it's useful to have a means of specifying that a group of storage &quot;fastened together with duct tape&quot; should be usable as though it were a single storage location.  It may also be useful to have a means of implicitly creating a wrapper object that can hold such a group, or extracting the contents thereof.</p>
<p>Some programmers view such things as being some weird broken form of object, rather than recognizing them for what they are: groups of storage locations held together with duct tape.</p>
<p>In C#, if one has types:</p>
<pre><code>class pointClass {public int x,y; };
struct pointStruct { public int x,y; };
</code></pre>
<p>along with an array of each type, the semantics of the struct will often be much clearer than those of the class.  For example, suppose one has an array of <code>pointClass</code> whose first element is a reference to a <code>pointClass</code> holding values <code>1,2</code>, and one wants the first element of the array to hold a reference to a <code>pointClass</code> instance with values <code>1,3</code>.  There are three ways this might happen:</p>
<ol>
<li><p>Replace the first element of the array with a reference to a new <code>pointClass</code> object which holds values <code>1,3</code>.</p>
</li>
<li><p>Modify the <code>y</code> field of the <code>pointClass</code> object to which the first element of the array holds a reference.</p>
</li>
<li><p>Identify some instance of <code>pointClass</code> which holds <code>1,3</code>, and will never be accessible by code that might try to never modify it, and store a reference to that within the array.</p>
</li>
</ol>
<p>Any of these might be the right approach, depending the application, but it's not always clear which one would be appropriate.  Selecting the wrong one may yield hard-to-track-down bugs.</p>
<p>If instead of holding a <code>pointClass</code>, the array had held an exposed-field <code>pointStruct</code>, then there would be no question about what should happen.  The second <code>int</code> values in the first element of the array should be changed to 3.  Since no &quot;reference&quot; to those values could exist outside the array, the question of whether the first element of the array identifies the same <code>pointStruct</code> instance as anything else in the universe would be simple to answer: the only references of any sort that could exist to the first element of the array would be a scope-limited &quot;byref&quot;; any byref that was created to identify that array element would throughout its lifetime identify that same element, and could not be detached from it, and any that wasn't thuus created could never identify the same element.</p>

CC BY-SA 4.0
2023-06-30T21:19:26.993Z
2023-07-01T05:39:50.033Z
2023-07-01T05:39:50.033Z
supercat
CC BY-SA 4.0
2023-07-01T05:42:31.863Z
@kaya3-supportthestrike: Thanks.  My main point is to emphasize the "group of storage locations stuck together with duct tape".  While a class object can kinda sorta mimic a group of storage locations stuck together with duct tape, I find myself annoyed at people who view structs as an inferior form of class, and think structs should try to imitate a class trying to imitate a bunch of storage locations stuck together with duct tape, rather than simply having a struct act like what it *actually is*.
supercat
<h1>Depends on the (runtime) semantic difference</h1>
<p>I think it depends on whether the semantic difference is big enough.</p>
<p>The distinction between <code>private</code> and <code>public</code> is meaningless, it's not a runtime semantic.</p>
<p>It makes sense to distinguish between <code>value types</code> and <code>reference types</code>, whose memory structure and runtime semantics are different.</p>
<hr />
<h1>My Design and Distinguish</h1>
<p>Allow me to introduce the difference between <a href="https://valkyrie-language.netlify.app/en/definition/structure.html#structure" rel="nofollow noreferrer">structure</a> and <a href="https://valkyrie-language.netlify.app/en/definition/structure.html#class" rel="nofollow noreferrer">class</a> in valkyrie language here.</p>
<p><code>class</code> is an out-of-the-box structure, suitable for daily use.</p>
<p>And <code>structure</code> is a professional, lower-level structure with more configurations, so it is not recommended for daily use.</p>
<h2>Data Layouts</h2>
<p><code>class</code> use auto layout, auto arrange fields, auto fill alignment</p>
<p><code>structure</code> use manually layout, the field order is equal to the writing order, and needs to be filled and aligned by itself.</p>
<h2>Auto Traits</h2>
<p>Many grammars in the valkyrie language are related to traits, and classes will automatically implement these traits.</p>
<pre class="lang-python prettyprint-override"><code>class Point {
    x: int,
    y: int,
}
# from `Constructor::construct`
Point(1, y: 2)
# from `Extractor::extract`
case Point(x, y): print(&quot;({x}, {y})&quot;)
# from `Equal::equal`
a == b || a != b
# from `Encode::encode`
p.encode::(Json)()
</code></pre>
<p>And <code>structure</code> have to be implemented by themselves.</p>
<h2>Auto Casts</h2>
<p>In the valkyrie language, subtypes need to implement cast to supertypes.</p>
<p><code>class</code> uses two private fields to store the parent class by default.</p>
<p><code>structure</code> does not generate anything automatically, you need to implement cast manually.</p>
<pre class="lang-scala prettyprint-override"><code>class C(B1, B2) { }

structure C(B1, B2) {
    private _b1: B1,
    private _b2: B2,
}
imply C: Cast(B1) {
    cast(self): B1 {
        self._b1;
    }
}
imply C: Cast(B2) {
    cast(self): B2 {
        self._b2;
    }
}
</code></pre>
<p>This mechanism is used to solve the situation where virtual base classes, repeated base classes, or staggered base classes can get better layout.</p>

CC BY-SA 4.0
2023-06-30T14:50:58.670Z
2023-06-30T14:50:58.670Z
Aster
<p>If we declare that the construct has no methods, private fields (so no hidden internal state) or inheritance, this has the same effect as using <code>bool</code> as a synonym for <code>int</code> in C-like languages, or keywords like <code>const</code>, <code>final</code>, <code>std::</code> and others similar. There is more context what it is, helping with readability.</p>
<p>It is possible to use an object, instance of the class, for everything. Or <code>int</code>, <code>char</code> as boolean, or <code>string</code> as <code>int</code>. This is just less readable.</p>

CC BY-SA 4.0
2023-06-30T04:40:20.417Z
2023-06-30T13:55:46.780Z
2023-06-30T13:55:46.780Z
Audrius Meškauskas
CC BY-SA 4.0
2023-06-30T13:56:44.707Z
Welcome! I made an edit which I think clarifies your intent, because at first I didn't understand that part of your answer. Please feel free to revert my edit or make a different one if I got it wrong.
kaya3
<h1>Not Necessarily</h1>
<p>Lots of modern languages agree with you, which is why we're seeing the rise of the concept called a <em>data class</em>. Basically, rather than having two completely disjoint concepts for &quot;OOP-style classes&quot; and &quot;data structures&quot;, we start with a full-featured notion of a <code>class</code> and then optionally add-on some functionality to make it behave more like a data structure when we want.</p>
<p>In Kotlin, the keyword is <code>data class</code>. In Java, it's <code>record</code>. In Python, it's a decorator called <code>@dataclass</code>. And in Scala, which arguably pioneered the concept, it's called a <code>case class</code>. The key point, in each of these cases, is that the thing we're talking about is still a <em>class</em>; it's just a class with a lot of extra behavior thrown in.</p>
<p>Common functionality included in this feature:</p>
<ul>
<li>Public fields, or automatically-generated getters for each field.</li>
<li>A constructor which takes values for all of the public fields as arguments.</li>
<li>A generated <code>toString()</code> which prints out all of the fields.</li>
<li>Structural equality and hashing.</li>
<li>A <code>copy</code> method which produces a new instance of the class, with a small number of fields changed.</li>
</ul>

CC BY-SA 4.0
2023-06-30T04:48:51.743Z
2023-06-30T04:48:51.743Z
Silvio Mayolo
CC BY-SA 4.0
2023-07-01T04:17:45.897Z
And then you have C# which has `class` and `struct` and recently added `record class` and `record struct`, which may be a (ahem) *record* number of structures to express classes.
Jörg W Mittag
<p>Keep in mind C++ has a heavy C inheritance. A class defined as struct in a C++ program, if it has no special features like virtual functions, is indistinguishable in memory from a PODS (Plain Old Data Struct) and having all of their members be publicly accessible as if being defined in a C program is all the better in that sense.</p>
<hr />
<p>If thinking of a new, C++ style language, the difference between struct and class could be to directly not allow any OOP features in a struct, for example member methods, inheritance etc, making <code>structs</code> essentially a C compatibility feature. It would also allow this language to do its' own thing with member ordering in the new style classes (enforce a special padding/alignment, add metadata, etc) while maintaining the expected structure ordering as defined by the platform's ABI in POD structures. The sky's the limit when you don't have to think about backwards compatibility like C++ does.</p>

CC BY-SA 4.0
2023-06-30T02:32:37.680Z
2023-06-30T02:32:37.680Z
kouta-kun
<p>For the most part, this distinction tends to reflect the history and evolution of languages.</p>
<p>Structures are a simple feature that most languages have had since they were originally designed. They existed in early languages such as PL/I and COBOL. They were also added easily to other languages, e.g. <code>DEFSTRUCT</code> in Lisp (<code>DEFSTRUCT</code> was originally a macro defined in a popular user-written library).</p>
<p>Classes are a more advanced feature that came later, mainly from object-oriented languages such as Smalltalk.</p>
<p>Over time, many of the older languages adopted OO features, including classes. Or, as in C++ and Objective C, they evolved into new languages. But structures were kept in the language for backward compatibility.</p>
<p>There's obvioiusly considerable overlap in their functionality. But even in C++, where the only technical difference is the default visibility of members (private vs public), programmers tend to conceptualize them differently. Structures tend to be used when you just need a simple container with named slots, while classes are used when you need OO features such as inheritance or polymorphism.</p>
<p>This usually makes programs easier to understand. When you see a structure definition, you can infer that you don't have to worry about fancy methods associated with it, or subclass relationships.</p>

CC BY-SA 4.0
2023-06-30T15:16:53.497Z
2023-06-30T15:16:53.497Z
Barmar
<p>If the difference really is very small then there does, as you say seem little purpose in distinguishing.  Sometimes the difference may be historical.  But the difference may not be small.</p>
<p>Common Lisp is an example of a language where there are two sorts of class-like thing which are quite distinct.  In CL's case the difference is both historical and justified by the semantic differences.</p>
<p>As originally defined, CL allowed you to define <em>structures</em> using the macro <a href="http://www.lispworks.com/documentation/lw70/CLHS/Body/m_defstr.htm" rel="nofollow noreferrer"><code>defstruct</code></a>.  Structures:</p>
<ul>
<li>have named fields, which can have defined types and init forms;</li>
<li>have accessors predefined for these fields;</li>
<li>support single-inheritance which might be done by inclusion;</li>
<li>usually are a distinct type although there is a special hack which allows <code>defstruct</code> to define 'structures' which are just lists or vectors, which is useful to wrap old code;</li>
<li>where a type is defined there will be appropriate subtype relationships;</li>
<li>and various other useful things.</li>
</ul>
<p>Structures in particular may not be portably redefined, so code can assume things about accessors: they can be inlined, type inference is possible &amp;c.</p>
<p>Since structures are (by default) distinct types which inherit from any parent structure type it's possible to build a simple object system using them.</p>
<p>In the final (so far) version of CL, CLOS, the Common Lisp Object System appeared, and with it classes defined with <a href="http://www.lispworks.com/documentation/HyperSpec/Body/m_defcla.htm" rel="nofollow noreferrer"><code>defclass</code></a>. These classes:</p>
<ul>
<li>have named slots ...</li>
<li>... which may or may not have readers, writers, or accessors (both), as well as other attributes;</li>
<li>support multiple inheritance;</li>
<li>are distinct types (see below);</li>
<li>there are appropriate subtype relationships;</li>
<li>support redefinition;</li>
<li>and many other useful things.</li>
</ul>
<p>Critically classes support redefinition: you can redefine a class and the behaviour in this case is specified.  Existing instances of the class get updated and you can intervene in this process in a well-defined way.  So for example if you remove a slot from a class you can write code which defines what happens in that case.  You can modify the inheritance graph as part of redefinition and this works.</p>
<p>CLOS also defines many other fancy features for classes defined with <code>defclass</code>.</p>
<p>CLOS does two and a half other things.</p>
<ul>
<li>Classes and types are largely unified: any class corresponds to a type, and many types have corresponding classes.  In particular the structure types defined by <code>defstruct</code> have corresponding classes.</li>
<li>Methods are not defined in classes but rather belong to generic functions, and may specialize on more than one argument.  Redefinition of methods is of course supported, as is the addition of new methods to existing generic functions.  Automatically-defined slot access functions are methods on generic functions, so you can use the whole machinery of generic functions with them.</li>
<li>Additionally a hairy definition of CLOS itself in terms of itself, the metaobject protocol, was <em>not</em> standardized, but many CL implementations have more-or-less compatible versions of it.</li>
</ul>
<p>The end result of this is that there are two families of classes:</p>
<ul>
<li>structure types are probably fast but limited, although you can use most of the machinery of generic functions with them (structure field accessors are <em>not</em> methods on generic finctions though);</li>
<li>classes defined with <code>defclass</code> are enormously flexible, with the full generic function machinery available, but probably both slower and larger.</li>
</ul>
<p>Although this tradeoff is partly historical, it's a good compromise in general.</p>

CC BY-SA 4.0
2023-06-30T19:18:10.090Z
2023-06-30T19:18:10.090Z
ignis volens
# Distinguishing classes from structures
Posted by: username_0 on 2023-06-30
Some languages have a concept of classes separately than structs. In C++ the only difference is whether the members are public or private by default. This seems redundant. Why have a separate `class` keyword for such a minor and trivial difference? In Swift the difference is whether they are reference types or value types.

Is there an advantage to include both in cases where the difference is so minor for example in C++? How else does or could `class` behave differently than a `struct` in other languages that would warrant having them separately?
**Tags:** data-structures classes
> **Comments:**
> **username_1**: There are almost unlimited ways that classes and structs "could" behave differently, but most of them wouldn't be useful. Perhaps it would be better if the question asked about what differences exist between classes and structs in other languages which have both.  
> **username_0**: @kaya3-supportthestrike The scope of the question is comparable to the scope of syntax questions - in which there are almost unlimited syntaxes possible.  
> **username_2**: I think it seems kind of weird to first come up with a feature (having both `class` and `struct`, with a distinction), then try to retroactively find a reason to have that feature.  
> **username_0**: @RydwolfPrograms Do you think I should change this to a *'Why would you have `class` and `struct` both if they're so similar?'*  
> **username_3**: Ultimately, `class` and `struct` are two arbitrary keywords you can have in a programming language. They don’t universally refer to any well-defined semantic concept, so this question is ill-defined. Pedantically, the answer to “could `class` behave different from `struct`?” is “yes, because they can behave absolutely however the language designer decides they should behave.”  
> **username_4**: The answers to this question seem to demostrate it is valuable.  
> **username_5**: @BruceAdams I agree, I originally voted to close and then to reopen because while the focus of the question is weird, in some other (non-C++) languages classes and structures are very different beasts and defining what exactly is a class or a structure could be very interesting.  
---
## 7 answers
### Answer by username_9 on 2023-06-30. Score: 8 | Accepted answer
# Not Necessarily

Lots of modern languages agree with you, which is why we're seeing the rise of the concept called a *data class*. Basically, rather than having two completely disjoint concepts for "OOP-style classes" and "data structures", we start with a full-featured notion of a `class` and then optionally add-on some functionality to make it behave more like a data structure when we want.

In Kotlin, the keyword is `data class`. In Java, it's `record`. In Python, it's a decorator called `@dataclass`. And in Scala, which arguably pioneered the concept, it's called a `case class`. The key point, in each of these cases, is that the thing we're talking about is still a *class*; it's just a class with a lot of extra behavior thrown in.

Common functionality included in this feature:

* Public fields, or automatically-generated getters for each field.
* A constructor which takes values for all of the public fields as arguments.
* A generated `toString()` which prints out all of the fields.
* Structural equality and hashing.
* A `copy` method which produces a new instance of the class, with a small number of fields changed.
> **Comments:**
> **username_10** (2023-07-01): And then you have C# which has `class` and `struct` and recently added `record class` and `record struct`, which may be a (ahem) *record* number of structures to express classes.  
---
### Answer by username_5 on 2023-06-30. Score: 6
Keep in mind C++ has a heavy C inheritance. A class defined as struct in a C++ program, if it has no special features like virtual functions, is indistinguishable in memory from a PODS (Plain Old Data Struct) and having all of their members be publicly accessible as if being defined in a C program is all the better in that sense.

---

If thinking of a new, C++ style language, the difference between struct and class could be to directly not allow any OOP features in a struct, for example member methods, inheritance etc, making `structs` essentially a C compatibility feature. It would also allow this language to do its' own thing with member ordering in the new style classes (enforce a special padding/alignment, add metadata, etc) while maintaining the expected structure ordering as defined by the platform's ABI in POD structures. The sky's the limit when you don't have to think about backwards compatibility like C++ does.
---
### Answer by username_11 on 2023-06-30. Score: 5
For the most part, this distinction tends to reflect the history and evolution of languages.

Structures are a simple feature that most languages have had since they were originally designed. They existed in early languages such as PL/I and COBOL. They were also added easily to other languages, e.g. `DEFSTRUCT` in Lisp (`DEFSTRUCT` was originally a macro defined in a popular user-written library).

Classes are a more advanced feature that came later, mainly from object-oriented languages such as Smalltalk.

Over time, many of the older languages adopted OO features, including classes. Or, as in C++ and Objective C, they evolved into new languages. But structures were kept in the language for backward compatibility.

There's obvioiusly considerable overlap in their functionality. But even in C++, where the only technical difference is the default visibility of members (private vs public), programmers tend to conceptualize them differently. Structures tend to be used when you just need a simple container with named slots, while classes are used when you need OO features such as inheritance or polymorphism.

This usually makes programs easier to understand. When you see a structure definition, you can infer that you don't have to worry about fancy methods associated with it, or subclass relationships.
---
### Answer by username_12 on 2023-06-30. Score: 4
If the difference really is very small then there does, as you say seem little purpose in distinguishing. Sometimes the difference may be historical. But the difference may not be small.

Common Lisp is an example of a language where there are two sorts of class-like thing which are quite distinct. In CL's case the difference is both historical and justified by the semantic differences.

As originally defined, CL allowed you to define *structures* using the macro [`defstruct`](http://www.lispworks.com/documentation/lw70/CLHS/Body/m_defstr.htm). Structures:

* have named fields, which can have defined types and init forms;
* have accessors predefined for these fields;
* support single-inheritance which might be done by inclusion;
* usually are a distinct type although there is a special hack which allows `defstruct` to define 'structures' which are just lists or vectors, which is useful to wrap old code;
* where a type is defined there will be appropriate subtype relationships;
* and various other useful things.

Structures in particular may not be portably redefined, so code can assume things about accessors: they can be inlined, type inference is possible &c.

Since structures are (by default) distinct types which inherit from any parent structure type it's possible to build a simple object system using them.

In the final (so far) version of CL, CLOS, the Common Lisp Object System appeared, and with it classes defined with [`defclass`](http://www.lispworks.com/documentation/HyperSpec/Body/m_defcla.htm). These classes:

* have named slots ...
* ... which may or may not have readers, writers, or accessors (both), as well as other attributes;
* support multiple inheritance;
* are distinct types (see below);
* there are appropriate subtype relationships;
* support redefinition;
* and many other useful things.

Critically classes support redefinition: you can redefine a class and the behaviour in this case is specified. Existing instances of the class get updated and you can intervene in this process in a well-defined way. So for example if you remove a slot from a class you can write code which defines what happens in that case. You can modify the inheritance graph as part of redefinition and this works.

CLOS also defines many other fancy features for classes defined with `defclass`.

CLOS does two and a half other things.

* Classes and types are largely unified: any class corresponds to a type, and many types have corresponding classes. In particular the structure types defined by `defstruct` have corresponding classes.
* Methods are not defined in classes but rather belong to generic functions, and may specialize on more than one argument. Redefinition of methods is of course supported, as is the addition of new methods to existing generic functions. Automatically-defined slot access functions are methods on generic functions, so you can use the whole machinery of generic functions with them.
* Additionally a hairy definition of CLOS itself in terms of itself, the metaobject protocol, was *not* standardized, but many CL implementations have more-or-less compatible versions of it.

The end result of this is that there are two families of classes:

* structure types are probably fast but limited, although you can use most of the machinery of generic functions with them (structure field accessors are *not* methods on generic finctions though);
* classes defined with `defclass` are enormously flexible, with the full generic function machinery available, but probably both slower and larger.

Although this tradeoff is partly historical, it's a good compromise in general.
---
### Answer by username_7 on 2023-06-30. Score: 3
Depends on the (runtime) semantic difference
I think it depends on whether the semantic difference is big enough.
The distinction between private and public is meaningless, it's not a runtime semantic.
It makes sense to distinguish between value types and reference types, whose memory structure and runtime semantics are different.

My Design and Distinguish
Allow me to introduce the difference between structure and class in valkyrie language here.
class is an out-of-the-box structure, suitable for daily use.
And structure is a professional, lower-level structure with more configurations, so it is not recommended for daily use.
Data Layouts
class use auto layout, auto arrange fields, auto fill alignment
structure use manually layout, the field order is equal to the writing order, and needs to be filled and aligned by itself.
Auto Traits
Many grammars in the valkyrie language are related to traits, and classes will automatically implement these traits.
class Point {
    x: int,
    y: int,
}
# from `Constructor::construct`
Point(1, y: 2)
# from `Extractor::extract`
case Point(x, y): print("({x}, {y})")
# from `Equal::equal`
a == b || a != b
# from `Encode::encode`
p.encode::(Json)()

And structure have to be implemented by themselves.
Auto Casts
In the valkyrie language, subtypes need to implement cast to supertypes.
class uses two private fields to store the parent class by default.
structure does not generate anything automatically, you need to implement cast manually.
class C(B1, B2) { }

structure C(B1, B2) {
    private _b1: B1,
    private _b2: B2,
}
imply C: Cast(B1) {
    cast(self): B1 {
        self._b1;
    }
}
imply C: Cast(B2) {
    cast(self): B2 {
        self._b2;
    }
}

This mechanism is used to solve the situation where virtual base classes, repeated base classes, or staggered base classes can get better layout.
---
### Answer by username_8 on 2023-06-30. Score: 3
If we declare that the construct has no methods, private fields (so no hidden internal state) or inheritance, this has the same effect as using `bool` as a synonym for `int` in C-like languages, or keywords like `const`, `final`, `std::` and others similar. There is more context what it is, helping with readability.

It is possible to use an object, instance of the class, for everything. Or `int`, `char` as boolean, or `string` as `int`. This is just less readable.
> **Comments:**
> **username_1** (2023-06-30): Welcome! I made an edit which I think clarifies your intent, because at first I didn't understand that part of your answer. Please feel free to revert my edit or make a different one if I got it wrong.  
---
### Answer by username_6 on 2023-06-30. Score: 2
In many situations, it's useful to have a means of specifying that a group of storage "fastened together with duct tape" should be usable as though it were a single storage location.  It may also be useful to have a means of implicitly creating a wrapper object that can hold such a group, or extracting the contents thereof.
Some programmers view such things as being some weird broken form of object, rather than recognizing them for what they are: groups of storage locations held together with duct tape.
In C#, if one has types:
class pointClass {public int x,y; };
struct pointStruct { public int x,y; };

along with an array of each type, the semantics of the struct will often be much clearer than those of the class.  For example, suppose one has an array of pointClass whose first element is a reference to a pointClass holding values 1,2, and one wants the first element of the array to hold a reference to a pointClass instance with values 1,3.  There are three ways this might happen:

Replace the first element of the array with a reference to a new pointClass object which holds values 1,3.

Modify the y field of the pointClass object to which the first element of the array holds a reference.

Identify some instance of pointClass which holds 1,3, and will never be accessible by code that might try to never modify it, and store a reference to that within the array.


Any of these might be the right approach, depending the application, but it's not always clear which one would be appropriate.  Selecting the wrong one may yield hard-to-track-down bugs.
If instead of holding a pointClass, the array had held an exposed-field pointStruct, then there would be no question about what should happen.  The second int values in the first element of the array should be changed to 3.  Since no "reference" to those values could exist outside the array, the question of whether the first element of the array identifies the same pointStruct instance as anything else in the universe would be simple to answer: the only references of any sort that could exist to the first element of the array would be a scope-limited "byref"; any byref that was created to identify that array element would throughout its lifetime identify that same element, and could not be detached from it, and any that wasn't thuus created could never identify the same element.
> **Comments:**
> **username_6** (2023-07-01): @kaya3-supportthestrike: Thanks.  My main point is to emphasize the "group of storage locations stuck together with duct tape".  While a class object can kinda sorta mimic a group of storage locations stuck together with duct tape, I find myself annoyed at people who view structs as an inferior form of class, and think structs should try to imitate a class trying to imitate a bunch of storage locations stuck together with duct tape, rather than simply having a struct act like what it *actually is*.  
---
