Found 7 bookmarks
Custom sorting
Link to Tomás’ note on why HKTs in Swift will be tricky with the language’s left-biasing of generic parameters
Link to Tomás’ note on why HKTs in Swift will be tricky with the language’s left-biasing of generic parameters
Immutable Conversations is a video series from 47 Degrees featuring casual conversations about important open source libraries with maintainers and contributors, and others in the Functional Programming community. On this episode, Alejandro Serrano has a socially distanced conversation with Tomás Ruiz-López about the adoption of functional programming within the industry, adding functional capabilities to Swift with the Bow library, and the usefulness of higher-kinded types. Learn more about Bow—a library for typed functional programming in Swift: https://bow-swift.io/ ------ Host: Alejandro Serrano Senior Software Engineer | 47 Degrees Twitter: https://twitter.com/trupill Guest: Tomás Ruiz-López Technical Lead | 47 Degrees Twitter: https://twitter.com/tomasruizlopez Immutable Conversations is a 47 Degrees Academy production. Elevate your educational experience with Functional Programming with the 47 Degrees Academy. https://www.47deg.com/trainings/academy/ #functionalprogramming #swiftlang #bowswift
·youtu.be·
Link to Tomás’ note on why HKTs in Swift will be tricky with the language’s left-biasing of generic parameters
Protocols III: Existential Spelling
Protocols III: Existential Spelling
Existentials and universals are [logical] “duals,” which means that one can be transformed into the other without losing its structure. So `AnySequence` is a universal type (generic) that’s equivalent to an explicit existential of `Sequence` (protocol). That’s why when you run into problems with protocols, your solution may be to convert it into generic structs (or vice versa). They solve the same problems in different ways with different trade-offs. And when you see “can only be used as a generic constraint,” what the compiler is really telling you is that protocols with associated types (PATs) don’t have an existential.
·robnapier.net·
Protocols III: Existential Spelling
Improving the UI of generics
Improving the UI of generics
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
·forums.swift.org·
Improving the UI of generics
swift-evolution/0244-opaque-result-types.md
swift-evolution/0244-opaque-result-types.md
Right now, if you want to abstract the return type of a declaration from its signature, existentials or manual type erasure are your only options, and these come with tradeoffs that are not always acceptable. Instead of declaring the specific return type of `EightPointedStar.shape`'s current implementation, all we really want to say is that it returns something that conforms to `Shape`. We propose the syntax `some Protocol`. An opaque return type can be thought of as putting the generic signature “to the right” of the function arrow; instead of being a type chosen by the caller that the callee sees as abstracted, the return type is chosen by the callee, and comes back to the caller as abstracted. or some composition thereof (joined with `&`)
·github.com·
swift-evolution/0244-opaque-result-types.md
Swift Generics Evolution - don’t panic
Swift Generics Evolution - don’t panic
it’s reassuring to know that the folks driving changes in Swift have a solid background in language design, and that they’re thinking about all manner of hard problems in order to make our lives easier. However, it makes me worry that people might be missing out on a truly exciting conversation about what might be coming in a future Swift version. The reason for the label “reverse generics” is that the flow of information is backwards from the existing system. Where right now, the caller binds generic types as it calls a function, the proposal would have the function itself bind the return types and pass concrete values back out.
·timekl.com·
Swift Generics Evolution - don’t panic