<p>I saw <a href="https://languagedesign.stackexchange.com/a/1631/38">this</a> answer which suggests tuple syntax, similar to that in Swift, where the elements can be named. However, how is that functionally different from a plain struct? Both are collections of named members in this case. I thought the purpose of tuples was just to have a collection of <strong>unnamed</strong> members, so if you can name tuple members, why would you have that construct separately from a struct?</p>

<tuple><struct>
How is a structure different from a tuple with named elements?
<p>Structures are usually nominally named -- two structure definitions with the same body are usually considered distinct, while this is not the case for tuples with named elements.</p>

CC BY-SA 4.0
2023-06-26T02:14:19.403Z
2023-06-26T02:14:19.403Z
ice1000
<p>Named tuples are tuples, with ordered elements exposed to the user in that order, and the names are <em>additional</em> access paths. Structs expose only field names, and any ordering of fields is purely representational. These are semantically different constructs, and you could see named tuples as a midpoint between conventional bare tuples and structs.</p>
<p>An obvious instance of this concept is in a relational database: table columns have both names and an order, and their rows could reasonably be labelled with either, or both. A named tuple is the construct that encapsulates both.</p>
<hr />
<p>In some cases, named tuples might be able to supplant structs, rather than the other way around, though any subtyping relationships would generally be different. There are feasible language designs here with named tuples as a primary data type. When names are mandatory, they are less suitable as a replacement for ordinary tuples, but optional or automatic names could allow them to fill all the niches.</p>


CC BY-SA 4.0
2023-06-24T02:51:04.813Z
2023-06-24T03:02:19.550Z
2023-06-24T03:02:19.550Z
Michael Homer
CC BY-SA 4.0
2023-06-24T03:21:50.180Z
In Swift, [both the names and the order of tuple fields matter, but in different contexts](https://chat.stackexchange.com/transcript/146046?m=63834864#63834864).
Bbrk24
CC BY-SA 4.0
2023-06-24T03:27:38.420Z
@Bbrk24 Yes, I'd expect them both to matter in every language (or else what's the point of them!). Exactly *where* name and position conformance matters is going to vary a bit, in defensible but incompatible ways.
Michael Homer
<h1>What does Swift actually do?</h1>
<p>Since we’re using Swift as a point of reference here, let’s look at Swift itself.</p>
<h2>Field order</h2>
<p>In a tuple, fields can be accessed by name or by position:</p>
<pre class="lang-swift prettyprint-override"><code>let foo = (x: 1, y: 2.0)
// foo.x == foo.0
// foo.y == foo.1
</code></pre>
<p>This means <strong>the compiler is allowed to reorder struct fields</strong>, but not tuple fields. As an implementation detail it currently doesn’t, but it could.</p>
<h2>Structural vs nominal typing</h2>
<p>Unlabelled tuples can be cast to labelled ones, and vice-versa, implicitly:</p>
<pre class="lang-swift prettyprint-override"><code>let foo: (a: Int, b: Int) = (1, 2)
let bar: (Int, Int) = foo
let baz: (x: Int, y: Int) = bar
</code></pre>
<p>Swift also has <em>tuple shuffle</em>, where two tuples that have the same set of labels are equivalent even if the labels are in a different order:</p>
<pre class="lang-swift prettyprint-override"><code>let foo: (x: Int, y: Float) = (1, 2.0)
let bar: (y: Float, x: Int) = foo
</code></pre>
<p>Both of these are reminiscent of <em>structural typing</em>. On the other hand, all other types in Swift are <em>nominal</em>, meaning equivalent structures are different types and you cannot implicitly cast between them.</p>
<h2>Just one element</h2>
<p>A struct with only one field is equivalent in layout to its singular field, but has its own vtable(s) and is a distinct type. A tuple with one element, on the other hand, is identical to the thing it contains in every way. As I pointed out in the answer you linked, this means you can put random <code>_:</code> in mathematical expressions and the compiler is fine with that.</p>
<h2>Implementation</h2>
<p>Protocols (Swift’s name for traits) can be implemented by structs, but not tuples. More generally, structs can have methods, computed properties, and private fields, while a tuple is just a collection of things.</p>
<h2>C bridging</h2>
<p>Swift guarantees that a homogeneous tuple, such as <code>(Int, Int, Int)</code>, is layout-identical to a fixed-length C array <code>intptr_t[3]</code>. However, Swift makes no such guarantee about structs, and Swift structs are not exposed to C — if you want a struct layout-compatible with C, you need to declare it in a C header file.</p>
<h2>The unit type</h2>
<p>Swift’s canonical unit type is the empty tuple, <code>()</code>. Functions that return this type may omit the <code>return</code> statement altogether, or say <code>return</code> rather than <code>return ()</code>. Similarly, functions that return <code>()</code> can be ignored without <code>@discardableResult</code>, and in fact it’s a compiler warning to assign it to a variable without an explicit type. None of this is true for an empty struct.</p>
<h2>Destructuring</h2>
<p>Swift lets you destructure tuples, but not structs:</p>
<pre class="lang-swift prettyprint-override"><code>let foo = (a: 1, b: 2)
(let a, let b) = foo
</code></pre>

CC BY-SA 4.0
2023-06-24T03:39:54.403Z
2023-06-24T11:55:38.613Z
2023-06-24T11:55:38.613Z
Bbrk24
CC BY-SA 4.0
2023-06-24T15:02:01.807Z
On the topic of nominative/structural and implementing protocols/traits, Rust does something interesting: in addition to structs and tuples, it has "tuple structs": tuples with names, and that you can implement things on (or from the alternative point of view, ordinary structs but with ordered instead of named arguments).
rydwolf
# How is a structure different from a tuple with named elements?
Posted by: username_0 on 2023-06-24
I saw [this](https://languagedesign.stackexchange.com/a/1631/38) answer which suggests tuple syntax, similar to that in Swift, where the elements can be named. However, how is that functionally different from a plain struct? Both are collections of named members in this case. I thought the purpose of tuples was just to have a collection of **unnamed** members, so if you can name tuple members, why would you have that construct separately from a struct?
**Tags:** tuple struct
---
## 3 answers
### Answer by username_3 on 2023-06-24. Score: 6 | Accepted answer
What does Swift actually do?
Since we’re using Swift as a point of reference here, let’s look at Swift itself.
Field order
In a tuple, fields can be accessed by name or by position:
let foo = (x: 1, y: 2.0)
// foo.x == foo.0
// foo.y == foo.1

This means the compiler is allowed to reorder struct fields, but not tuple fields. As an implementation detail it currently doesn’t, but it could.
Structural vs nominal typing
Unlabelled tuples can be cast to labelled ones, and vice-versa, implicitly:
let foo: (a: Int, b: Int) = (1, 2)
let bar: (Int, Int) = foo
let baz: (x: Int, y: Int) = bar

Swift also has tuple shuffle, where two tuples that have the same set of labels are equivalent even if the labels are in a different order:
let foo: (x: Int, y: Float) = (1, 2.0)
let bar: (y: Float, x: Int) = foo

Both of these are reminiscent of structural typing. On the other hand, all other types in Swift are nominal, meaning equivalent structures are different types and you cannot implicitly cast between them.
Just one element
A struct with only one field is equivalent in layout to its singular field, but has its own vtable(s) and is a distinct type. A tuple with one element, on the other hand, is identical to the thing it contains in every way. As I pointed out in the answer you linked, this means you can put random _: in mathematical expressions and the compiler is fine with that.
Implementation
Protocols (Swift’s name for traits) can be implemented by structs, but not tuples. More generally, structs can have methods, computed properties, and private fields, while a tuple is just a collection of things.
C bridging
Swift guarantees that a homogeneous tuple, such as (Int, Int, Int), is layout-identical to a fixed-length C array intptr_t[3]. However, Swift makes no such guarantee about structs, and Swift structs are not exposed to C — if you want a struct layout-compatible with C, you need to declare it in a C header file.
The unit type
Swift’s canonical unit type is the empty tuple, (). Functions that return this type may omit the return statement altogether, or say return rather than return (). Similarly, functions that return () can be ignored without @discardableResult, and in fact it’s a compiler warning to assign it to a variable without an explicit type. None of this is true for an empty struct.
Destructuring
Swift lets you destructure tuples, but not structs:
let foo = (a: 1, b: 2)
(let a, let b) = foo
> **Comments:**
> **username_4** (2023-06-24): On the topic of nominative/structural and implementing protocols/traits, Rust does something interesting: in addition to structs and tuples, it has "tuple structs": tuples with names, and that you can implement things on (or from the alternative point of view, ordinary structs but with ordered instead of named arguments).  
---
### Answer by username_1 on 2023-06-26. Score: 4
Structures are usually nominally named -- two structure definitions with the same body are usually considered distinct, while this is not the case for tuples with named elements.
---
### Answer by username_2 on 2023-06-24. Score: 3
Named tuples are tuples, with ordered elements exposed to the user in that order, and the names are *additional* access paths. Structs expose only field names, and any ordering of fields is purely representational. These are semantically different constructs, and you could see named tuples as a midpoint between conventional bare tuples and structs.

An obvious instance of this concept is in a relational database: table columns have both names and an order, and their rows could reasonably be labelled with either, or both. A named tuple is the construct that encapsulates both.

---

In some cases, named tuples might be able to supplant structs, rather than the other way around, though any subtyping relationships would generally be different. There are feasible language designs here with named tuples as a primary data type. When names are mandatory, they are less suitable as a replacement for ordinary tuples, but optional or automatic names could allow them to fill all the niches.
> **Comments:**
> **username_3** (2023-06-24): In Swift, [both the names and the order of tuple fields matter, but in different contexts](https://chat.stackexchange.com/transcript/146046?m=63834864#63834864).  
> **username_2** (2023-06-24): @Bbrk24 Yes, I'd expect them both to matter in every language (or else what's the point of them!). Exactly *where* name and position conformance matters is going to vary a bit, in defensible but incompatible ways.  
---
