<p>I was reminded in <a href="https://proofassistants.stackexchange.com/a/2226/2432">this answer</a>
(to my perhaps naive question <a href="https://proofassistants.stackexchange.com/questions/2225/what-is-needed-to-move-from-design-by-contract-to-using-a-proof-assistant">https://proofassistants.stackexchange.com/questions/2225/what-is-needed-to-move-from-design-by-contract-to-using-a-proof-assistant</a>)
that the C++ type system is unsound.</p>
<p>I take this to mean that you can in theory do <em>evil things<sup>(tm)</sup></em> like:</p>
<ul>
<li>reinterpret_cast a string to a int or visa versa.</li>
<li>rely on <a href="https://languagedesign.stackexchange.com/q/481/285">undefined behaviour</a></li>
<li>accidentally use memory before it is allocated or after it is freed</li>
</ul>
<p>But I also believe you can restrict yourself to a using sound subset of an unsound language. In fact formal verification is one means to achieve that.
The escape hatches are there if you really need them.</p>
<p>So in terms of programming language design:</p>
<ul>
<li><strong>What are its benefits and limitations?</strong></li>
<li><strong>Likewise what are the benefits and consequences of being unsound?</strong></li>
</ul>
<p>You might also consider in your answers:</p>
<ul>
<li>What is a good definition of <a href="https://en.wikipedia.org/wiki/Soundness" rel="noreferrer">soundness</a> from the PL perspective?</li>
<li>Isn't it always possible to restrict yourself to a sound subset in a language that supports some unsound escape hatches? Like rust's <code>unsafe</code> keyword for example.</li>
</ul>

<soundness>
What are the consequences of an unsound type system?
CC BY-SA 4.0
2023-06-08T19:11:48.417Z
[This Swift forums post](https://forums.swift.org/t/typealias-conformance-to-protocols-why-cant-this-simple-thing-be-implemented/63302/41) covers soundness vs completeness pretty well, imo
Bbrk24
CC BY-SA 4.0
2023-06-08T21:50:44.943Z
This question feels extremely broad to me; just "what is soundness" alone would be a whole question on its own. Just the title question probably sustains itself too. Maybe it can be reasonably pared down to just a single topic (and the others into their own questions)?
Michael Homer
CC BY-SA 4.0
2023-06-09T07:33:09.003Z
The question is essential a "pros and cons" of soundness vs unsoundness. That obviously requires a definition of soundness. I've linked to the wikipedia one but that is more mathematical. So I'm just leaving a hint to the answerer that they might want to explain it in a more PL fashion. Still I've reword to try and fix this.
Bruce Adams
<p>Here's a straightforward definition that may be practically useful for language designers:</p>
<blockquote>
<p>A static type system is sound if, whenever an expression <em>x</em> has a static type <em>T</em>, the value of <em>x</em> at runtime is always a member of the type <em>T</em>.</p>
</blockquote>
<p>Note that <em>x</em> here is a stand-in for any kind of expression, not just an expression which consists of a simple variable name.</p>
<p>The consequences of unsoundness depend on the nature of the language or its implementation, particularly whether or not there is <a href="https://en.wikipedia.org/wiki/Run-time_type_information" rel="noreferrer">runtime type information</a> (RTTI) which can be used to check types at runtime:</p>
<ul>
<li>If there is no RTTI, or RTTI exists but is not used to check types at runtime for expressions with unsound static types, then unsoundness implies <a href="https://en.wikipedia.org/wiki/Memory_safety" rel="noreferrer">memory unsafety</a>. C++ and Rust are in this category.</li>
<li>If RTTI is used to check the types of expressions, then an unsound static type system at worst degrades to a dynamic type system; there is not necessarily any guarantee what type an expression's value will have at runtime, but values of one type won't be used as if they are values of another type. Instead, if a sub-expression's value has an unexpected type at runtime, either an error is thrown at runtime, or the operation is evaluated by <a href="https://en.wikipedia.org/wiki/Dynamic_binding" rel="noreferrer">dynamic dispatch</a> depending on the runtime type. Java and Typescript are in this category.</li>
</ul>
<hr />
<p>Memory unsafety is something that almost all modern languages want to avoid, so most languages in the first category aim for a completely sound type system. If you do choose to have an unsound type system, you must at least give enough guidance to users so that they can use it in a safe way.</p>
<p>This may mean offering a subset of the language in which the type system is sound (e.g. Rust without <code>unsafe</code>), or writing a detailed specification for what the programmer must ensure about their own code to guarantee memory safety (e.g. the <a href="https://doc.rust-lang.org/nomicon/index.html" rel="noreferrer">Rustonomicon</a>). In the latter case, it's the programmer's job to prove for themselves that the types of their expression are correct, and the compiler cannot check the proof.</p>
<p>Languages in this category only really benefit from unsoundness to the extent that there are useful, correct programs which can be written in the language but whose correctness the compiler cannot verify.</p>
<hr />
<p>On the other hand, languages in the second category can benefit considerably from unsoundness; since memory safety is still guaranteed (the implementation checks at runtime before doing anything that might be unsafe), an unsound static type system can be thought of as somewhere along the spectrum between dynamic types and (sound) static types. This gives <a href="https://en.wikipedia.org/wiki/Gradual_typing" rel="noreferrer">gradual typing</a>.</p>
<p>There's a much bigger discussion to be had about the advantages and disadvantages of gradual typing, and I think it's out of scope for this question, but I'll point you at a few other Q&amp;As which are more-or-less relevant:</p>
<ul>
<li><a href="https://languagedesign.stackexchange.com/q/1342/89">Why does Python ignore type hints?</a></li>
<li><a href="https://languagedesign.stackexchange.com/q/604/89">What are the run-time implications of gradual typing?</a></li>
<li><a href="https://languagedesign.stackexchange.com/q/587/89">What are the pros and cons of static typing?</a></li>
</ul>

CC BY-SA 4.0
2023-06-08T21:08:01.180Z
2023-06-08T21:08:01.180Z
kaya3
CC BY-SA 4.0
2023-11-10T16:39:43.657Z
One thing that annoys me is how little priority some language maintainers seem to place upon the ease of maintaining memory safety.  Many programs will be fed a mixture of correct and nonsensical data, with very loose requirements on how some forms of invalid data are handled.  Having a programming language provide just enough built in checks to ensure memory safety may be much cheaper and safer than requiring that programmers include much more rigorous checks to prevent all meaningless operations that could result from nonsensical data, but some language maintainers favor the latter approach.
supercat
<p>Well, there's a whole web site — <a href="https://counterexamples.org/" rel="noreferrer">Counterexamples in Type Systems</a> — that lists all main <em>sources</em> of unsoundness in type systems and their consequences.</p>
<p>In general, in <em>sound</em> type systems &quot;well-typed programs cannot go wrong&quot; — they don't crash, don't corrupt memory, don't throw exceptions (unless intentionally), don't have data races and so on (the list varies from language to language and type system to type system). In <em>unsound</em> type systems you don't have such guarantees...</p>
<p>So if you have certain guarantees at <em>compile-time</em> (through sound type-checking) you don't need to check the same thing at <em>run-time</em>, meaning you can have both fast and safe programs. OTOH if you want safety in an <em>unsound</em> language, you'll have to perform these checks at run-time. There's no free lunch. Some languages just go unsafe — check neither at compile-time, nor run-time — but I wouldn't call it a &quot;free ride&quot;...</p>

CC BY-SA 4.0
2023-06-12T07:04:34.737Z
2023-06-12T07:04:34.737Z
Alex Chichigin
<p>Java <a href="https://dl.acm.org/doi/10.1145/2983990.2984004" rel="noreferrer">accidentally had an unsound type system for a decade</a>, and nobody noticed or cared (except, eventually, Nada Amin). It had no consequences and no impact on anything in that time.</p>
<p>This is an extreme case in some respects, but it highlights that soundness, in and of itself, isn't always a meaningful quality in a real-world system. It's an absolute property: either you have it, or you don't. The situations that made Java unsound just never arose in real-world situations where they mattered. Here's an unsound program (from Amin &amp; Tate, OOPSLA 2016):</p>
<pre class="lang-java prettyprint-override"><code>class Unsound {
  static class Constrain&lt;A, B extends A&gt; {}
  static class Bind&lt;A&gt; {
    &lt;B extends A&gt;
    A upcast(Constrain&lt;A,B&gt; constrain, B b) {
      return b;
    }
  }
  static &lt;T,U&gt; U coerce(T t) {
    Constrain&lt;U,? super T&gt; constrain = null;
    Bind&lt;U&gt; bind = new Bind&lt;U&gt;();
    return bind.upcast(constrain, t);
  }
  public static void main(String[] args) {
    String zero = Unsound.&lt;Integer,String&gt;coerce(0);
  }
}
</code></pre>
<p>This was consistent with the Java Language Specification and so should have compiled, but it would crash at run time in a place where it shouldn't be able to. It's a great find and Amin &amp; Tate did an excellent job of illustrating how it came to be. Until then, though, this problem hadn't created any practical problems. The unsoundness was lurking, but in a place that it wasn't going to do any harm. Did it matter that Java was unsound? Probably yes, still, but actual consequences are hard to pinpoint.</p>
<hr />
<p>So what are the consequences of an unsound type system? <strong>Maybe none at all!</strong> It can also lead to serious problems at run time where data is reinterpreted dangerously. Which situation you're in depends on the language, on where the unsoundness lies, and on how people actually write code in it. Unsoundness is a necessary, but not sufficient, property to have the adverse consequences associated with it.</p>
<p>Languages with <em>intentionally</em> unsound type systems are making trade-offs for better expressivity, for performance, or for compatibility, and these consequences are generally explicitly known. Languages that intend to be sound, like Java, can be accidentally unsound, and in doing so they may still have minimal consequences; they can also open up major correctness, security, and reliability problems when properties the programmer expected to hold didn't.</p>
<p>If the language really is sound, it eliminates the whole class of potential errors where something isn't the type you expect it to be. That is a powerful property that you gain by giving up on some of the expressive power you could have had — and that lost power may not matter when you planned for it! Of course, it is always possible to stick to a sound <em>subset</em> within an unsound language, since at the very least the empty subset is sound, but in general you may lose out on a lot of the expressivity the language does have by doing that, just because the unsound parts may be very significant in a language that's designed with them in mind; you may lose nothing at all, because you're writing Java and the unsound cases would never have occurred to you.</p>

CC BY-SA 4.0
2023-06-09T03:54:50.830Z
2023-06-09T03:54:50.830Z
Michael Homer
CC BY-SA 4.0
2023-06-09T13:41:16.920Z
I’m surprised that `Constrain<U, ? super T>` declaration is legal without a `U super T` constraint on `coerce` itself. I’m also coming from the perspective of Swift, which leans so heavily towards soundness it gets in your way sometimes.
Bbrk24
CC BY-SA 4.0
2023-06-09T21:25:28.987Z
@Bbrk24 That program definitely *shouldn't* have been permitted! It just was consistent with the rules at the time. It's broken down [in the paper](https://namin.seas.harvard.edu/sites/projects.iq.harvard.edu/files/unsound-oopsla16.pdf), but in short there were ambiguities in the rules for *implicit* bounds on types that enabled it (among other things). Those have all been fixed now, so the current system is sound-as-far-as-we-know.
Michael Homer
# What are the consequences of an unsound type system?
Posted by: username_0 on 2023-06-08
I was reminded in [this answer](https://proofassistants.stackexchange.com/a/2226/2432)
(to my perhaps naive question <https://proofassistants.stackexchange.com/questions/2225/what-is-needed-to-move-from-design-by-contract-to-using-a-proof-assistant>)
that the C++ type system is unsound.

I take this to mean that you can in theory do *evil things(tm)* like:

* reinterpret\_cast a string to a int or visa versa.
* rely on [undefined behaviour](https://languagedesign.stackexchange.com/q/481/285)
* accidentally use memory before it is allocated or after it is freed

But I also believe you can restrict yourself to a using sound subset of an unsound language. In fact formal verification is one means to achieve that.
The escape hatches are there if you really need them.

So in terms of programming language design:

* **What are its benefits and limitations?**
* **Likewise what are the benefits and consequences of being unsound?**

You might also consider in your answers:

* What is a good definition of [soundness](https://en.wikipedia.org/wiki/Soundness) from the PL perspective?
* Isn't it always possible to restrict yourself to a sound subset in a language that supports some unsound escape hatches? Like rust's `unsafe` keyword for example.
**Tags:** soundness
> **Comments:**
> **username_1**: [This Swift forums post](https://forums.swift.org/t/typealias-conformance-to-protocols-why-cant-this-simple-thing-be-implemented/63302/41) covers soundness vs completeness pretty well, imo  
> **username_2**: This question feels extremely broad to me; just "what is soundness" alone would be a whole question on its own. Just the title question probably sustains itself too. Maybe it can be reasonably pared down to just a single topic (and the others into their own questions)?  
> **username_0**: The question is essential a "pros and cons" of soundness vs unsoundness. That obviously requires a definition of soundness. I've linked to the wikipedia one but that is more mathematical. So I'm just leaving a hint to the answerer that they might want to explain it in a more PL fashion. Still I've reword to try and fix this.  
---
## 3 answers
### Answer by username_2 on 2023-06-09. Score: 12 | Accepted answer
Java accidentally had an unsound type system for a decade, and nobody noticed or cared (except, eventually, Nada Amin). It had no consequences and no impact on anything in that time.
This is an extreme case in some respects, but it highlights that soundness, in and of itself, isn't always a meaningful quality in a real-world system. It's an absolute property: either you have it, or you don't. The situations that made Java unsound just never arose in real-world situations where they mattered. Here's an unsound program (from Amin & Tate, OOPSLA 2016):
class Unsound {
  static class Constrain {}
  static class Bind {
    
    A upcast(Constrain constrain, B b) {
      return b;
    }
  }
  static  U coerce(T t) {
    Constrain constrain = null;
    Bind bind = new Bind();
    return bind.upcast(constrain, t);
  }
  public static void main(String[] args) {
    String zero = Unsound.coerce(0);
  }
}

This was consistent with the Java Language Specification and so should have compiled, but it would crash at run time in a place where it shouldn't be able to. It's a great find and Amin & Tate did an excellent job of illustrating how it came to be. Until then, though, this problem hadn't created any practical problems. The unsoundness was lurking, but in a place that it wasn't going to do any harm. Did it matter that Java was unsound? Probably yes, still, but actual consequences are hard to pinpoint.

So what are the consequences of an unsound type system? Maybe none at all! It can also lead to serious problems at run time where data is reinterpreted dangerously. Which situation you're in depends on the language, on where the unsoundness lies, and on how people actually write code in it. Unsoundness is a necessary, but not sufficient, property to have the adverse consequences associated with it.
Languages with intentionally unsound type systems are making trade-offs for better expressivity, for performance, or for compatibility, and these consequences are generally explicitly known. Languages that intend to be sound, like Java, can be accidentally unsound, and in doing so they may still have minimal consequences; they can also open up major correctness, security, and reliability problems when properties the programmer expected to hold didn't.
If the language really is sound, it eliminates the whole class of potential errors where something isn't the type you expect it to be. That is a powerful property that you gain by giving up on some of the expressive power you could have had — and that lost power may not matter when you planned for it! Of course, it is always possible to stick to a sound subset within an unsound language, since at the very least the empty subset is sound, but in general you may lose out on a lot of the expressivity the language does have by doing that, just because the unsound parts may be very significant in a language that's designed with them in mind; you may lose nothing at all, because you're writing Java and the unsound cases would never have occurred to you.
> **Comments:**
> **username_1** (2023-06-09): I’m surprised that `Constrain<U, ? super T>` declaration is legal without a `U super T` constraint on `coerce` itself. I’m also coming from the perspective of Swift, which leans so heavily towards soundness it gets in your way sometimes.  
> **username_2** (2023-06-09): @Bbrk24 That program definitely *shouldn't* have been permitted! It just was consistent with the rules at the time. It's broken down [in the paper](https://namin.seas.harvard.edu/sites/projects.iq.harvard.edu/files/unsound-oopsla16.pdf), but in short there were ambiguities in the rules for *implicit* bounds on types that enabled it (among other things). Those have all been fixed now, so the current system is sound-as-far-as-we-know.  
---
### Answer by username_3 on 2023-06-08. Score: 10
Here's a straightforward definition that may be practically useful for language designers:

> A static type system is sound if, whenever an expression *x* has a static type *T*, the value of *x* at runtime is always a member of the type *T*.

Note that *x* here is a stand-in for any kind of expression, not just an expression which consists of a simple variable name.

The consequences of unsoundness depend on the nature of the language or its implementation, particularly whether or not there is [runtime type information](https://en.wikipedia.org/wiki/Run-time_type_information) (RTTI) which can be used to check types at runtime:

* If there is no RTTI, or RTTI exists but is not used to check types at runtime for expressions with unsound static types, then unsoundness implies [memory unsafety](https://en.wikipedia.org/wiki/Memory_safety). C++ and Rust are in this category.
* If RTTI is used to check the types of expressions, then an unsound static type system at worst degrades to a dynamic type system; there is not necessarily any guarantee what type an expression's value will have at runtime, but values of one type won't be used as if they are values of another type. Instead, if a sub-expression's value has an unexpected type at runtime, either an error is thrown at runtime, or the operation is evaluated by [dynamic dispatch](https://en.wikipedia.org/wiki/Dynamic_binding) depending on the runtime type. Java and Typescript are in this category.

---

Memory unsafety is something that almost all modern languages want to avoid, so most languages in the first category aim for a completely sound type system. If you do choose to have an unsound type system, you must at least give enough guidance to users so that they can use it in a safe way.

This may mean offering a subset of the language in which the type system is sound (e.g. Rust without `unsafe`), or writing a detailed specification for what the programmer must ensure about their own code to guarantee memory safety (e.g. the [Rustonomicon](https://doc.rust-lang.org/nomicon/index.html)). In the latter case, it's the programmer's job to prove for themselves that the types of their expression are correct, and the compiler cannot check the proof.

Languages in this category only really benefit from unsoundness to the extent that there are useful, correct programs which can be written in the language but whose correctness the compiler cannot verify.

---

On the other hand, languages in the second category can benefit considerably from unsoundness; since memory safety is still guaranteed (the implementation checks at runtime before doing anything that might be unsafe), an unsound static type system can be thought of as somewhere along the spectrum between dynamic types and (sound) static types. This gives [gradual typing](https://en.wikipedia.org/wiki/Gradual_typing).

There's a much bigger discussion to be had about the advantages and disadvantages of gradual typing, and I think it's out of scope for this question, but I'll point you at a few other Q&As which are more-or-less relevant:

* [Why does Python ignore type hints?](https://languagedesign.stackexchange.com/q/1342/89)
* [What are the run-time implications of gradual typing?](https://languagedesign.stackexchange.com/q/604/89)
* [What are the pros and cons of static typing?](https://languagedesign.stackexchange.com/q/587/89)
> **Comments:**
> **username_4** (2023-11-10): One thing that annoys me is how little priority some language maintainers seem to place upon the ease of maintaining memory safety.  Many programs will be fed a mixture of correct and nonsensical data, with very loose requirements on how some forms of invalid data are handled.  Having a programming language provide just enough built in checks to ensure memory safety may be much cheaper and safer than requiring that programmers include much more rigorous checks to prevent all meaningless operations that could result from nonsensical data, but some language maintainers favor the latter approach.  
---
### Answer by username_5 on 2023-06-12. Score: 7
Well, there's a whole web site — [Counterexamples in Type Systems](https://counterexamples.org/) — that lists all main *sources* of unsoundness in type systems and their consequences.

In general, in *sound* type systems "well-typed programs cannot go wrong" — they don't crash, don't corrupt memory, don't throw exceptions (unless intentionally), don't have data races and so on (the list varies from language to language and type system to type system). In *unsound* type systems you don't have such guarantees...

So if you have certain guarantees at *compile-time* (through sound type-checking) you don't need to check the same thing at *run-time*, meaning you can have both fast and safe programs. OTOH if you want safety in an *unsound* language, you'll have to perform these checks at run-time. There's no free lunch. Some languages just go unsafe — check neither at compile-time, nor run-time — but I wouldn't call it a "free ride"...
---
