https://t.co/lM1D5Ldk0O— Joe Groff (@jckarter) December 4, 2020

We could think of type-level-abstracted return types as doing the same thing but at the type level; you give a function generic arguments as inputs, and it gives a certain return type back. ​ This roughly follows the progression of `impl Trait` in Rust, where it was first introduced only for return types, then was generalized to be able to appear structurally in both argument and return types. We think this is a reasonable first step because it directly addresses the biggest functionality gap in the generics model. After that first step, there are a few fairly orthogonal language change discussions we can have, some of which are already underway

The Either monad specifically only models early exit on Left without resumption. You'd need something more powerful like Cont to be able to resume. There are Haskell libraries that provide extensible effects using free monads, like https://t.co/rsvEbVULPs— Joe Groff (@jckarter) July 21, 2019

Internet debate is very effective at changing minds— Joe Groff (@jckarter) May 1, 2019

It's my fault, sorry. In the early days of Swift, we had a closure syntax that was very similar to traditional Javascript, func (arg: Type, arg: Type) -> Return { ... }. While this is nice and regular syntax, it is of course also very bulky and awkward if you're trying to support expressive functional APIs, such as map/filter on collections, or if you want libraries to be able to provide closure-based APIs that feel like extensions of the language. Our earliest adopters at Apple complained about...

Ideas often get copied from well-known established projects into new projects with the background behind those decisions lost. Projects should have a "https://t.co/iLkkhljAHY" to lay out regretful design choices that can't be reversed for time, compatibility, etc. reasons— Joe Groff (@jckarter) January 14, 2019