Here's what frustrates me about programming languages. Something obvious doesn't work for years. Then the team fixes it and announces it like a feature. Dart 3.12 just did exactly that with private named parameters. But let's be fair. At least they fixed it.
Hi, my name is Tom Smykowski, I'm a staff full-stack engineer. I build and scale SaaS platforms to millions of users, working end-to-end from system architecture to frontend to mobile. On this blog I explore programming languages, frameworks, and the tools that shape how we build software.
Programming language teams have a peculiar talent for celebrating the removal of their own mistakes. You spend years working around a limitation that never made sense. Then one day the changelog arrives, and there it is: "New Feature!" What they mean is: "We finally stopped blocking something that should have worked from day one."
Dart 3.12 is a solid release. Private named parameters, primary constructors, AI integration, and Firebase Functions in Dart. Some of it is genuinely new. Some of it is long overdue.
The Boilerplate Tax Nobody Asked For
Dart has this neat trick with constructors. You write this.fieldName and the field initializes itself. No redundant assignments. Clean and simple.
Until you want a private field with a named parameter.
Privacy in Dart means slapping an underscore at the start. _secretValue is private. publicValue is public. Straightforward enough. The problem? Before version 3.12, the compiler threw a tantrum when you tried combining these two concepts.
In a codebase with 150 model classes, this adds up to thousands of lines that serve no purpose except satisfying a compiler limitation.
The full article covers what changed in 3.12, primary constructors borrowed from Kotlin, Genkit for AI integration, Firebase Functions in Dart, Agentic Hot Reload, and the breaking changes you need to know about before upgrading.