How to Totally Fix PartialFunction
summary
Argument: PartialFunction breaks expectations by inheriting from Function1 and redefining apply, which weakens Liskov substitution and causes surprising runtime MatchErrors. Concrete proposals: split semantics with an explicit unsafeApply and safe apply/orElse, or remove the inheritance so Function1 and PartialFunction are distinct, or implement PartialFunction on an unboxed Option/opaque type to avoid boxing. Notes: small compatibility fixes already merged for 2.13, full migration costs and compiler/typechecks are the main obstacles.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 2:54Agenda
- 3:44Definitions
- 8:33PartialFunction
- 15:07Partial Function When
- 17:51Implementation
- 25:56Partial Functions
- 27:20Proposal
- 31:36Proposed Solution
- 37:22Alternative Solution
related talks
42mPolymorphic Function Types in Scala 3
35mFunctional Programming is Terrible
40mPolymorphic Function Types in Scala 3
44mFunction reuse is just wishful thinking
32mApplicative: The Origin Story
53mFunction Reuse is just Wishful Thinking
59mIntro to FP in Scala: Exploring a Toolbox for Solving Problems - Part 3 of 6
23mDuality and How to Delete Half (minus ε) of Your Code
