<p>A <a href="https://en.wikipedia.org/wiki/Unit_type" rel="noreferrer">Unit Type</a> is one inhabited by exactly one value, and, due to the lack of possible discrimination (<em>&quot;no information able to be held&quot;</em>), is reducible to the 0-tuple.<br />
Meanwhile a <a href="https://en.wikipedia.org/wiki/Singleton_%28mathematics%29" rel="noreferrer">Singleton</a> is one inhabited by exactly one value, and of which Set Theory says is a 1-tuple.</p>
<p>What are the differences between those two concepts, if any, and if there is none what is this difference in cardinality?<br />
Do both coexist in the same nomenclatures?<br />
And, given a <code>(x: a) -&gt; (y: b) -&gt; (x | y)</code> function type (read <em>&quot;takes an <code>a</code> called <code>x</code> and a <code>b</code> called <code>y</code>, and returns either <code>x</code> or <code>y</code>&quot;</em>) where <code>a</code> and <code>b</code> are different, what is the correct and/or accepted terminology to refer to <code>x</code> and <code>y</code>?</p>

<types><terminology>
What are the differences between Unit and Singleton Types?
CC BY-SA 4.0
2023-06-15T19:19:54.190Z
Your link to "singleton" is to the mathematical meaning of that term (i.e. a set with one element), not to the meaning in computer programming. A "singleton" as in the OOP singleton pattern is not a one-tuple, it's a type with one value.
kaya3
CC BY-SA 4.0
2023-06-15T19:23:16.583Z
@kaya3-supportthestrike If you're referring to the [Singleton Pattern](https://en.wikipedia.org/wiki/Singleton_pattern) as seen in OO, I would assume it is a particular implementation of the Set Theory concept. Am I wrong?
Longinus
CC BY-SA 4.0
2023-06-15T19:29:25.430Z
In set theory if you say something like "let S be a singleton set", this means S is a set of size 1, not that there is only one value that S can have. Singleton in everyday language means "something there is only one of", or "something that is alone; not part of a collection of multiple things", so the Singleton Pattern is more in line with the former meaning and the mathematical use of the word is more in line with the latter. The only connection is that for a unit type, the set of all possible values of that type is a singleton set; not that singleton sets are values of that type.
kaya3
<blockquote>
<p>What are the differences between those two concepts, if any, and if there is none what is this difference in cardinality?</p>
</blockquote>
<p>One can consider a Unit type/set a one example of a Singleton type/set. In contrast to other singletons, Unit type (by definition/construction) has extremely boring value — a unit value that has no structure. In that sense it's isomorphic to an empty set or a 0-tuple.</p>
<p>In set theory other singleton <em>values</em> can have structure, in particular they might be sets themselves, and not even necessarily singleton sets. In type theory values of singleton types might have structure too, and thus can be inspected at run-time.</p>
<blockquote>
<p>Do both coexist in the same nomenclatures?</p>
</blockquote>
<p>There are too many different (albeit etymologically related) notions of a &quot;singleton&quot;. Apart from already mentioned singleton <em>sets</em> and singleton pattern from OOP, there are <a href="https://hackage.haskell.org/package/singletons" rel="noreferrer">singleton <em>types</em></a> from Haskell...</p>
<blockquote>
<p>And, given a <code>(x: a) -&gt; (y: b) -&gt; (x | y)</code> function type (read &quot;takes an <code>a</code> called <code>x</code> and a <code>b</code> called <code>y</code>, and returns either <code>x</code> or <code>y</code>&quot;) where <code>a</code> and <code>b</code> are different, what is the correct and/or accepted terminology to refer to <code>x</code> and <code>y</code>?</p>
</blockquote>
<p>This is an instance of a Dependent Function (aka Π-type), and <code>x</code> and <code>y</code> are simply the (names of) parameters of a said function.</p>

CC BY-SA 4.0
2023-06-16T10:58:39.447Z
2023-06-16T10:58:39.447Z
Alex Chichigin
<p>Type-theoretically, a 1-tuple is just isomorphic to whatever is contained in that tuple. For example <code>tuple&lt;int&gt;</code> is isomorphic to <code>int</code>: I can map every <code>int</code> to a unique <code>tuple&lt;int&gt;</code> and vice versa.</p>
<p>A singleton type is simply a type <code>T</code> where, every time the program is run, we only instantiate a single (traditionally mutable) value. It can have any shape that is needed for the program. I don't know of any language that encodes &quot;singleton-ness&quot; as an explicit static property, instead relying on things like private constructors and not exposing any methods that allow code outside of the implementation to indirectly create new instances. That doesn't mean <code>T</code> only has one element, it can have many elements, so it is not a singleton set. Just like the type containing all ASCII strings of length &lt;= 1000 contains 1.622×10^2107 elements without problems.</p>

CC BY-SA 4.0
2023-06-19T23:41:49.567Z
2023-06-19T23:41:49.567Z
Jasmijn
CC BY-SA 4.0
2023-06-20T03:26:27.933Z
"we only instantiate a single value," "that doesn't mean T only has one element." This sounds contradictory to me. How can have a type, at the same time, have 1 and more or less than 1 member? Also TypeScript, Scala and Racket all feature first-class singletons. Many languages also feature `null`, `true` and `false` as singletons (Kotlin, TS, PHP, Zig, D, C++, ...). Wrt tuple cardinality: I was mentioning the cardinality of a type's set of inhabitants - not an actual `tuple` type.
Longinus
CC BY-SA 4.0
2023-06-20T03:41:16.480Z
(eg. where `int` itself already is an n-tuple with `n > 1`; and where if "int" means "32bits," it is a 4294967296-tuple)
Longinus
CC BY-SA 4.0
2023-06-20T08:51:37.917Z
Ah, I thought you were referring to the [singleton pattern](https://en.wikipedia.org/wiki/Singleton_pattern). The types of singletons like `null`, `true` and `false` (if `true` and `false` have different types rather than `bool` being inhabited by 2 values) are isomorphic to the unit type. In the way you describe int32 as a 4294967296-tuple, the unit type is a 1-tuple, but types are generally described as sets of values, not as tuples of those values.
Jasmijn
<p>I think the main difference from a language design perspective, is that a unit type is a <em>value type</em>, whereas a singleton type (in OOP) is a <em>reference type</em>. See <a href="https://en.wikipedia.org/wiki/Value_type_and_reference_type" rel="nofollow noreferrer">value types and reference types</a> on Wikipedia.</p>
<p>A unit type has one <em>value</em>, but there might be many instances of that value (if they are represented in memory at all; in some implementations, unit types occupy no memory). Usually, there is no need to compare instances of a unit type by reference instead of by value, and particularly in functional languages it's not even possible to, but in some languages it is (<a href="https://play.rust-lang.org/?version=stable&amp;mode=debug&amp;edition=2021&amp;gist=6b25418b8dfb0db7d8d8611c04226153" rel="nofollow noreferrer">Rust playground link</a>):</p>
<pre class="lang-rust prettyprint-override"><code>#[derive(PartialEq, Eq)]
struct UnitType;

fn main() {
    let a = UnitType;
    let b = UnitType;
    
    println!(&quot;Equal by value: {}&quot;, a == b);
    // true
    
    println!(&quot;Equal by reference: {}&quot;, std::ptr::eq(&amp;a, &amp;b));
    // false
}
</code></pre>
<p>On the other hand, a singleton type has one <em>instance</em>, and there might be many references to that instance, but they are all equal by reference, not just by value.</p>
<hr />
<p>There are some other differences in how unit types and singleton types are used in practice.</p>
<p>Generally, a unit type is used when some value must be represented but there is no information for that value to convey, e.g. the return value of a void function. Since a unit value is not meant to be used for anything, it has no methods or properties.</p>
<p>On the other hand, a singleton type in an object-oriented language exists to provide some functionality, so it typically does have methods and possibly also fields. It might implement some interfaces, and you might need to acquire a lock on the instance for some purposes. Access to the singleton instance might even be restricted in some way (e.g. <code>sun.misc.Unsafe</code>) because the singleton instance provides functionality which shouldn't be used everywhere.</p>
<hr />
<blockquote>
<p>what is this difference in cardinality?</p>
</blockquote>
<p>This appears to be a confusion about types (which can be represented as a set of all members of the type) vs. values. To say that the unit type is like an empty tuple means that the unit <em>value</em> is an empty tuple; that is, <code>Unit</code> is a type whose only member is <code>()</code>. But this means that the set of all members of <code>Unit</code> is equal to <code>{()}</code>, i.e. a set containing the empty tuple. So the value is a tuple of length zero, whereas the type is represented by a set of cardinality one.</p>

CC BY-SA 4.0
2023-06-15T20:11:20.027Z
2023-06-15T21:25:30.037Z
2023-06-15T21:25:30.037Z
kaya3
CC BY-SA 4.0
2023-06-17T07:25:49.513Z
what languages have multiple instances of an unit type? your example doesn't work since you implemented it in userland, and has different semantics than usual compiler-backed unit types.
RubenVerg
CC BY-SA 4.0
2023-06-17T07:36:11.290Z
@RubenVerg I'm not sure why you think the example I gave in Rust "doesn't work" ─ the type is a unit type and it has two instances which are not equal by reference. This is not a peculiarity of user-defined types in Rust, [the same works with the traditional empty tuple unit type](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=bd799069e6a0cc4f9502d06bb993457d). If that's not "compiler-backed" then I don't know what you are using that term to mean.
kaya3
CC BY-SA 4.0
2023-06-17T07:58:16.980Z
"Unit type" generally refers to the type that "void" functions return, not any type which is mathematically an unit type.
RubenVerg
CC BY-SA 4.0
2023-06-17T08:02:47.333Z
@RubenVerg Well, `()` is the type returned by void functions in Rust. But if you still object, then perhaps you will want to make edits to correct [Wikipedia](https://en.wikipedia.org/wiki/Unit_type#In_programming_languages) and [the official Rust handbook](https://doc.rust-lang.org/book/ch03-02-data-types.html#the-tuple-type), both of which consider `()` to be a unit type in Rust. Personally, I will continue to go by the plain definition that a unit type is one inhabited by a single value, and what I observe to be common usage.
kaya3
CC BY-SA 4.0
2023-06-17T12:45:03.020Z
"a(n) unit type" vs "the unit type" is important here. if the unit type of rust `()` can have multiple instances, that is as far as I can tell an oddity among languages
RubenVerg
CC BY-SA 4.0
2023-06-17T18:15:12.407Z
@RubenVerg It's not an oddity at all; what's unusual about Rust is that you can acquire references to `()`. Otherwise you would never be able to observe that there can be different instances, as the concept of instances would not be relevant for the language's semantics ─ as I mentioned, this is true in functional languages, and it is a clear distinction between unit types and singleton classes. The distinction between "a" and "the" here does not matter for my answer since the question is about "unit types", not "the unit type" or "the designated unit type returned by void functions".
kaya3
CC BY-SA 4.0
2023-06-18T08:20:29.483Z
I guess the whole concept of instances is not important when considering unit types and can be seen as an implementation detail, whereas it is the defining property for singletons
RubenVerg
CC BY-SA 4.0
2023-06-20T00:05:34.110Z
`std::ptr::eq(&a, &b)` is false for any `a` and `b` of any type, because they're different variables. Try [`std::ptr::eq(a, b)` where `a` and `b` are both `&UnitType`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0a5dd9beb8b5d8a2f42c1bb8eeb9dd50) instead, that gives true and true. [You can still get different references to `UnitType`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b53d2114318ada250d392f05f9ee7aff).
Jasmijn
CC BY-SA 4.0
2023-06-20T10:17:21.337Z
@Jasmijn I don't understand your objection. Yes, the two references `&a` and `&b` in my example are different because they refer to two different variables each of which owns its value. That is *why* they are not equal by reference in Rust's semantics; it remains a fact that they are *not* equal by reference, despite referring to equal values.
kaya3
CC BY-SA 4.0
2023-06-20T10:32:09.863Z
@kaya3-supportthestrike The point is that `std::ptr::eq(&a, &b)` is trivially false, it doesn't tell you anything about the behaviour of `UnitType`.
Jasmijn
CC BY-SA 4.0
2023-06-20T10:36:10.867Z
@Jasmijn Things which are trivially false are still false. The fact that it is false literally tells you that there are two distinct references to values of type `UnitType`, which implies there are two distinct instances of that type. Just because something is trivial doesn't mean nothing can be inferred from it.
kaya3
CC BY-SA 4.0
2023-06-20T11:07:07.347Z
@kaya3-supportthestrike Yes, there are two distinct references to values of type `UnitType`, no, that doesn't necessarily mean there are two distinct instances of that type. Two different references can reference the same instance, as is the case here.
Jasmijn
CC BY-SA 4.0
2023-06-20T12:13:34.363Z
@Jasmijn If they referenced the same instance then they would be equal by reference. `a` and `b` are not the same instance and cannot be in Rust's ownership model, since they have different owners.
kaya3
<p>A unit type is one that explicitly has no information content: there is a single value with no further meaning, and it only indicates completion.</p>
<p>Singleton types retain (some) information content. For example, a number of languages permit using string or numeric literals as types that can hold exactly that value, and no other; these types can be meaningfully disjoined, so <code>1 | 2</code> may be the type that is either the number one or two; this will be a subtype of the integer type, and the value can be extracted to that type. The values of singleton types can be inspected and used as meaningful values in the customary ways of the language, while the value of the unit type is merely present.</p>
<p>Singleton types may also be a realisation of what would be an algebraic data type terminal in another language, as a special kind of constant with static checking. In some object-oriented languages, singleton types can be created from an object reference. Scala is one such language:</p>
<pre class="lang-scala prettyprint-override"><code>object A { def greeting = &quot;Hello&quot; }
var a : A.type = A
var x : Any = a
x match {
    case n : A.type =&gt; 1
    case _ =&gt; 2
}
</code></pre>
<p>Scala has the <a href="https://docs.scala-lang.org/sips/42.type.html" rel="noreferrer">literal types</a> from above too, representing singleton types of those literal values.</p>
<p>The relation to a mathematical singleton set is in the conception of types as sets of all their values; this is not universally the model of types people use, but is a very common one. A singleton type has one value and equates to the set of that value alone, but there can be many of these singleton types in the program. In some systems, <em>every</em> distinct value has a corresponding singleton type whether it is used or not.</p>
<hr />
<p>The Singleton pattern as in the GoF is a way of enabling a single-valued value with chosen methods on it by inhibiting the creation of other instances of a class. These are sometimes sentinel values or used just for first-class values encapsulating shared state and behaviour, often <em>not</em> of the singleton type but a supertype. This is to some extent overloaded terminology; in a true singleton type, there is only one value, so constructing another one just doesn’t arise, and the pattern is an artefact of the classical structure of those languages.</p>

CC BY-SA 4.0
2023-06-15T19:55:35.040Z
2023-06-15T21:13:08.837Z
2023-06-15T21:13:08.837Z
Michael Homer
# What are the differences between Unit and Singleton Types?
Posted by: username_0 on 2023-06-15
A [Unit Type](https://en.wikipedia.org/wiki/Unit_type) is one inhabited by exactly one value, and, due to the lack of possible discrimination (*"no information able to be held"*), is reducible to the 0-tuple.  
Meanwhile a [Singleton](https://en.wikipedia.org/wiki/Singleton_%28mathematics%29) is one inhabited by exactly one value, and of which Set Theory says is a 1-tuple.

What are the differences between those two concepts, if any, and if there is none what is this difference in cardinality?  
Do both coexist in the same nomenclatures?  
And, given a `(x: a) -> (y: b) -> (x | y)` function type (read *"takes an `a` called `x` and a `b` called `y`, and returns either `x` or `y`"*) where `a` and `b` are different, what is the correct and/or accepted terminology to refer to `x` and `y`?
**Tags:** types terminology
> **Comments:**
> **username_1**: Your link to "singleton" is to the mathematical meaning of that term (i.e. a set with one element), not to the meaning in computer programming. A "singleton" as in the OOP singleton pattern is not a one-tuple, it's a type with one value.  
> **username_0**: @kaya3-supportthestrike If you're referring to the [Singleton Pattern](https://en.wikipedia.org/wiki/Singleton_pattern) as seen in OO, I would assume it is a particular implementation of the Set Theory concept. Am I wrong?  
> **username_1**: In set theory if you say something like "let S be a singleton set", this means S is a set of size 1, not that there is only one value that S can have. Singleton in everyday language means "something there is only one of", or "something that is alone; not part of a collection of multiple things", so the Singleton Pattern is more in line with the former meaning and the mathematical use of the word is more in line with the latter. The only connection is that for a unit type, the set of all possible values of that type is a singleton set; not that singleton sets are values of that type.  
---
## 4 answers
### Answer by username_5 on 2023-06-15. Score: 10 | Accepted answer
A unit type is one that explicitly has no information content: there is a single value with no further meaning, and it only indicates completion.
Singleton types retain (some) information content. For example, a number of languages permit using string or numeric literals as types that can hold exactly that value, and no other; these types can be meaningfully disjoined, so 1 | 2 may be the type that is either the number one or two; this will be a subtype of the integer type, and the value can be extracted to that type. The values of singleton types can be inspected and used as meaningful values in the customary ways of the language, while the value of the unit type is merely present.
Singleton types may also be a realisation of what would be an algebraic data type terminal in another language, as a special kind of constant with static checking. In some object-oriented languages, singleton types can be created from an object reference. Scala is one such language:
object A { def greeting = "Hello" }
var a : A.type = A
var x : Any = a
x match {
    case n : A.type => 1
    case _ => 2
}

Scala has the literal types from above too, representing singleton types of those literal values.
The relation to a mathematical singleton set is in the conception of types as sets of all their values; this is not universally the model of types people use, but is a very common one. A singleton type has one value and equates to the set of that value alone, but there can be many of these singleton types in the program. In some systems, every distinct value has a corresponding singleton type whether it is used or not.

The Singleton pattern as in the GoF is a way of enabling a single-valued value with chosen methods on it by inhibiting the creation of other instances of a class. These are sometimes sentinel values or used just for first-class values encapsulating shared state and behaviour, often not of the singleton type but a supertype. This is to some extent overloaded terminology; in a true singleton type, there is only one value, so constructing another one just doesn’t arise, and the pattern is an artefact of the classical structure of those languages.
---
### Answer by username_2 on 2023-06-16. Score: 5
> What are the differences between those two concepts, if any, and if there is none what is this difference in cardinality?

One can consider a Unit type/set a one example of a Singleton type/set. In contrast to other singletons, Unit type (by definition/construction) has extremely boring value — a unit value that has no structure. In that sense it's isomorphic to an empty set or a 0-tuple.

In set theory other singleton *values* can have structure, in particular they might be sets themselves, and not even necessarily singleton sets. In type theory values of singleton types might have structure too, and thus can be inspected at run-time.

> Do both coexist in the same nomenclatures?

There are too many different (albeit etymologically related) notions of a "singleton". Apart from already mentioned singleton *sets* and singleton pattern from OOP, there are [singleton *types*](https://hackage.haskell.org/package/singletons) from Haskell...

> And, given a `(x: a) -> (y: b) -> (x | y)` function type (read "takes an `a` called `x` and a `b` called `y`, and returns either `x` or `y`") where `a` and `b` are different, what is the correct and/or accepted terminology to refer to `x` and `y`?

This is an instance of a Dependent Function (aka Π-type), and `x` and `y` are simply the (names of) parameters of a said function.
---
### Answer by username_3 on 2023-06-19. Score: 2
Type-theoretically, a 1-tuple is just isomorphic to whatever is contained in that tuple. For example `tuple` is isomorphic to `int`: I can map every `int` to a unique `tuple` and vice versa.

A singleton type is simply a type `T` where, every time the program is run, we only instantiate a single (traditionally mutable) value. It can have any shape that is needed for the program. I don't know of any language that encodes "singleton-ness" as an explicit static property, instead relying on things like private constructors and not exposing any methods that allow code outside of the implementation to indirectly create new instances. That doesn't mean `T` only has one element, it can have many elements, so it is not a singleton set. Just like the type containing all ASCII strings of length <= 1000 contains 1.622×10^2107 elements without problems.
> **Comments:**
> **username_0** (2023-06-20): "we only instantiate a single value," "that doesn't mean T only has one element." This sounds contradictory to me. How can have a type, at the same time, have 1 and more or less than 1 member? Also TypeScript, Scala and Racket all feature first-class singletons. Many languages also feature `null`, `true` and `false` as singletons (Kotlin, TS, PHP, Zig, D, C++, ...). Wrt tuple cardinality: I was mentioning the cardinality of a type's set of inhabitants - not an actual `tuple` type.  
> **username_0** (2023-06-20): (eg. where `int` itself already is an n-tuple with `n > 1`; and where if "int" means "32bits," it is a 4294967296-tuple)  
> **username_3** (2023-06-20): Ah, I thought you were referring to the [singleton pattern](https://en.wikipedia.org/wiki/Singleton_pattern). The types of singletons like `null`, `true` and `false` (if `true` and `false` have different types rather than `bool` being inhabited by 2 values) are isomorphic to the unit type. In the way you describe int32 as a 4294967296-tuple, the unit type is a 1-tuple, but types are generally described as sets of values, not as tuples of those values.  
---
### Answer by username_1 on 2023-06-15. Score: 1
I think the main difference from a language design perspective, is that a unit type is a value type, whereas a singleton type (in OOP) is a reference type. See value types and reference types on Wikipedia.
A unit type has one value, but there might be many instances of that value (if they are represented in memory at all; in some implementations, unit types occupy no memory). Usually, there is no need to compare instances of a unit type by reference instead of by value, and particularly in functional languages it's not even possible to, but in some languages it is (Rust playground link):
#[derive(PartialEq, Eq)]
struct UnitType;

fn main() {
    let a = UnitType;
    let b = UnitType;
    
    println!("Equal by value: {}", a == b);
    // true
    
    println!("Equal by reference: {}", std::ptr::eq(&a, &b));
    // false
}

On the other hand, a singleton type has one instance, and there might be many references to that instance, but they are all equal by reference, not just by value.

There are some other differences in how unit types and singleton types are used in practice.
Generally, a unit type is used when some value must be represented but there is no information for that value to convey, e.g. the return value of a void function. Since a unit value is not meant to be used for anything, it has no methods or properties.
On the other hand, a singleton type in an object-oriented language exists to provide some functionality, so it typically does have methods and possibly also fields. It might implement some interfaces, and you might need to acquire a lock on the instance for some purposes. Access to the singleton instance might even be restricted in some way (e.g. sun.misc.Unsafe) because the singleton instance provides functionality which shouldn't be used everywhere.


what is this difference in cardinality?

This appears to be a confusion about types (which can be represented as a set of all members of the type) vs. values. To say that the unit type is like an empty tuple means that the unit value is an empty tuple; that is, Unit is a type whose only member is (). But this means that the set of all members of Unit is equal to {()}, i.e. a set containing the empty tuple. So the value is a tuple of length zero, whereas the type is represented by a set of cardinality one.
> **Comments:**
> **username_4** (2023-06-17): what languages have multiple instances of an unit type? your example doesn't work since you implemented it in userland, and has different semantics than usual compiler-backed unit types.  
> **username_1** (2023-06-17): @RubenVerg I'm not sure why you think the example I gave in Rust "doesn't work" ─ the type is a unit type and it has two instances which are not equal by reference. This is not a peculiarity of user-defined types in Rust, [the same works with the traditional empty tuple unit type](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=bd799069e6a0cc4f9502d06bb993457d). If that's not "compiler-backed" then I don't know what you are using that term to mean.  
> **username_4** (2023-06-17): "Unit type" generally refers to the type that "void" functions return, not any type which is mathematically an unit type.  
> **username_1** (2023-06-17): @RubenVerg Well, `()` is the type returned by void functions in Rust. But if you still object, then perhaps you will want to make edits to correct [Wikipedia](https://en.wikipedia.org/wiki/Unit_type#In_programming_languages) and [the official Rust handbook](https://doc.rust-lang.org/book/ch03-02-data-types.html#the-tuple-type), both of which consider `()` to be a unit type in Rust. Personally, I will continue to go by the plain definition that a unit type is one inhabited by a single value, and what I observe to be common usage.  
> **username_4** (2023-06-17): "a(n) unit type" vs "the unit type" is important here. if the unit type of rust `()` can have multiple instances, that is as far as I can tell an oddity among languages  
> **username_1** (2023-06-17): @RubenVerg It's not an oddity at all; what's unusual about Rust is that you can acquire references to `()`. Otherwise you would never be able to observe that there can be different instances, as the concept of instances would not be relevant for the language's semantics ─ as I mentioned, this is true in functional languages, and it is a clear distinction between unit types and singleton classes. The distinction between "a" and "the" here does not matter for my answer since the question is about "unit types", not "the unit type" or "the designated unit type returned by void functions".  
> **username_4** (2023-06-18): I guess the whole concept of instances is not important when considering unit types and can be seen as an implementation detail, whereas it is the defining property for singletons  
> **username_3** (2023-06-20): `std::ptr::eq(&a, &b)` is false for any `a` and `b` of any type, because they're different variables. Try [`std::ptr::eq(a, b)` where `a` and `b` are both `&UnitType`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0a5dd9beb8b5d8a2f42c1bb8eeb9dd50) instead, that gives true and true. [You can still get different references to `UnitType`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b53d2114318ada250d392f05f9ee7aff).  
> **username_1** (2023-06-20): @Jasmijn I don't understand your objection. Yes, the two references `&a` and `&b` in my example are different because they refer to two different variables each of which owns its value. That is *why* they are not equal by reference in Rust's semantics; it remains a fact that they are *not* equal by reference, despite referring to equal values.  
> **username_3** (2023-06-20): @kaya3-supportthestrike The point is that `std::ptr::eq(&a, &b)` is trivially false, it doesn't tell you anything about the behaviour of `UnitType`.  
> **username_1** (2023-06-20): @Jasmijn Things which are trivially false are still false. The fact that it is false literally tells you that there are two distinct references to values of type `UnitType`, which implies there are two distinct instances of that type. Just because something is trivial doesn't mean nothing can be inferred from it.  
> **username_3** (2023-06-20): @kaya3-supportthestrike Yes, there are two distinct references to values of type `UnitType`, no, that doesn't necessarily mean there are two distinct instances of that type. Two different references can reference the same instance, as is the case here.  
> **username_1** (2023-06-20): @Jasmijn If they referenced the same instance then they would be equal by reference. `a` and `b` are not the same instance and cannot be in Rust's ownership model, since they have different owners.  
---
