Found 9 bookmarks
Newest
Why making Never a bottom type is hard (see Pinboard profile for notes)
Why making Never a bottom type is hard (see Pinboard profile for notes)
In theory, `Never` can be a substitute for every type, since you have no instance to call any methods on, but that breaks down with static methods since those don’t need an instance. Right, the issue is with static and initializer requirements. The `Never` type itself can be a subtype of all types in the language but that does not mean that `Never` can conform to all protocols. So, it gets hairy when you introduce generalized existentials into the language. i.e. `Never` needs to be a subtype of those existentials without necessarily conforming to the protocol. Related, SE-0217: https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/222
·github.com·
Why making Never a bottom type is hard (see Pinboard profile for notes)
The Littlest Type
The Littlest Type
In type theory, an uninhabited type is often called a bottom type, and written as ⊥. A bottom type is a subtype of every other type. So `Never` would be an `Int` and a `String` and a `UIViewController` and every other type. The opposite is the top type (⊤), the supertype of every other type. In Swift, that’s `Any`.
·robnapier.net·
The Littlest Type
Parse, don’t validate
Parse, don’t validate
but `parseNonEmpty` gives the caller access to the information it learned, while `validateNonEmpty` just throws it away. Consider: what is a parser? Really, a parser is just a function that consumes less-structured input and produces more-structured output.
·lexi-lambda.github.io·
Parse, don’t validate
Book Review: The Little Typer
Book Review: The Little Typer
A dependent type is a type that is parameterized by a value. Lots of languages have types that are parameterized by other types, like `List`, but those are not dependent types. Dependent types are parameterized by instances of types.
·nickdrozd.github.io·
Book Review: The Little Typer
“Never use booleans”
“Never use booleans”
One of my first interactions with a Principal 1 at Amazon was a design review for a design owned by a team that was not mine, merely adjacent to mine. Because I was 21 and a dumbass, I thought that this older guy would hew closer to a PM or a manager and say some sort of irrelevant/ignorant set of remarks rather than a bunch of clever, reasonable, and forward-looking things, and of course the latter is what he did. Amazon’s flavor of title to designate “extremely distinguished engineer” ↩
·jmduke.com·
“Never use booleans”