Good afternoon Swift Evolution.
As an active member of the Swift community since day one, I've read and responded to countless pitches and proposals and ideas for how to push Swift forward. I have decided to synthesize them all into The Final Pitch for a universal feature clearly desired by all users thus far.
Chaos as Bottom
- Proposal: SE-NNNN
- Authors: Robert Widmann, Baphomet
- Review Manager: TBD
- Status: Awaiting implementation
During the review process, add the following fields as needed:
- Implementation: Not on your life, pal
- Decision Notes: Pre-Accepted By Order Of Hair-Force One
Introduction
A well-studied property of type systems featuring inheritance is the presence of a lattice structure over the set of types and the inherits-from relation. However, class types in Swift do not quite have the structure of a full lattice (in particular, we have a Bounded Meet-Semilattice) because we lack a distinguished "greatest lower bound" on typing. In short, we lack Never as a Bottom Type.
Since the question has been raised multiple times to great confusion, I take it as gospel that this feature will eventually wind its way into the language. And if it isn't designed by me, I'm never going to be satisfied until I tank discussion around it and beat my interlocutors into submission. Consider this proposal an act of mercy on my part.
Today, the standard library includes a declaration for the type Never - coded as an enums with no cases:
public enum Never {}
The compiler also includes special typing and control-flow checking rules that treat calls to never-returning functions like fatalError as return-type-polymorphic terminators:
func synthesize<T>(_ type: T.self) -> T {
fatalError("Nah")
}
While this is an admirable first step, I believe that the standard library doesn't go far enough, and that Never is not a rich enough representation of the bottom type in our lattice. For this purpose, I propose the introduction of Chaos, the type of a computation that is capable of doing literally anything to your program at any time, as the true bottom type.
Motivation
Since the dawn of programming language theory, scientists, mathematicians, and engineers have studied the semantics of computation in all its forms. In the process, they invested enormous amounts of energy and time applying their research in noble pursuit of higher-level programming languages that facilitate human creativity and ingenuity and will most certainly drive the human race towards a bright machine-integrated future.
And then some dudes with beards made C happen - and boy howdy did people like that a lot more than studying lambda calculus (or, heaven forbid, implementing CPL).
One thing C makes abundantly clear is that Chaos as a feature sells. Not only that, but C recognized a clear maxim of the human psyche that all those ivory-tower academics ignored: The natural state of human endeavors is Chaos. So C facilitated Chaos - through undefined behavior, through a commitment to severely bounded expressiveness over correctness, and an unwavering belief that any integer, no matter where it came from or what its job prospects were, could be a pointer - and it was good profitable.
In the quest for safety, modern programming languages have literally ignored profitability and instability as desirable mass-market features. Because the market has spoken and checks notes Java is the most popular language?!
Whoops.
Let me start again:
One thing that Java makes abundantly clear is that Chaos as a feature sells. 3 billion devices running Java can't be wrong, right?
Proposed solution
We (being the infernal 'We') propose the introduction of the type-which-must-not-be-named Chaos.
As it has no declaration in the standard library, but ought to have values as inhabitants to be a useful construct, we propose an attribute to signal a value should have the type of Chaos;
@poison
A storage declaration may be annotated @poisoned (not to be confused with the pragma in heinous GNU C because good god) shall have its value replaced by any bitpattern. The semantics of a poisoned value match the semantics of poison values in LLVM.
To aid the spread of chaos, an aggregate definition may be marked @poison to poison every member. A poisoned function may launch nukes†.
As an attribute and not a type, the Swift community is free to propose future formalized definitions of Chaos as they see fit, without having to constrain themselves to a single universal declaration and without having to continually submit Chaos-adjacent proposals.
Source compatibility
This proposal is strictly additive.
Effect on ABI stability
The ABI is Strong and Stable.
Alternatives considered
Did you not read the bit about silencing competing voices?
† This proposal contravenes both the Geneva Convention and the iTunes terms of service.