dart-lang/language: Where Dart's Design and Evolution Happen
Design of the Dart language
At a glance
- What is it?
- dart-lang/language is the official repository for designing and tracking changes to the Dart programming language. It holds the language specification, feature proposals at various stages, and the documented process that the Dart team follows from idea to shipped feature. It is not where the Dart compiler or SDK lives, but it is where the decisions that shape them are made.
- Who is it for?
- dart-lang/language is useful for Dart developers who want to understand why the language is the way it is, follow features in progress, or argue for a new language capability through the documented proposal process. It is not a starting point for learning Dart, compiling code, or filing SDK bugs.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 12 days ago.
- What is it written in?
- Mainly TeX, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 25, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What This Repository Is and Who It Serves
dart-lang/language is a governance and specification repository. It is where the Dart language team records language design decisions, proposes new features, debates trade-offs, and publishes the formal specification. The Dart implementation lives in other repositories; this one holds the design process.
The repository serves three groups. Language team members use it to author proposals, run the design process, and maintain the specification. External contributors use it to propose features, report language design problems, and participate in the public discussion of upcoming changes. Dart users who want to understand why a feature works the way it does, or who want to follow a feature in progress, can read through the accepted/ and working/ directories.
As of February 2026, the language team consists of nine engineers: Leaf Petersen, Lasse R.H. Nielsen, Bob Nystrom, Erik Ernst, Nate Bosch, Jake MacDonald, Paul Berry, Kallen Tu, and David Morgan. Michael Thomsen serves as product manager. Erik Ernst also maintains the official language specification.
The last push was on 2026-09-18. The repository is not archived.
Repository Layout: Where Each Stage of a Feature Lives
The repository top level organizes content by the stage of each proposal. The working/ directory holds features actively being designed. The accepted/ directory holds proposals that have been approved and are being or have been implemented. The archive/ directory holds proposals that were explored but not accepted. The inactive/ directory holds proposals that are not currently being pursued but have not been formally rejected.
The specification/ directory holds the formal Dart language specification, maintained by Erik Ernst. The doc/ directory contains process documentation including the file life_of_a_language_feature.md, which is the canonical reference for how a feature moves from idea to implementation.
The resources/ directory holds supporting materials, and the templates/ directory provides templates for new proposals. The tools/ directory contains scripts used to maintain the repository.
The lean/ directory holds a Lean formalization, suggesting the team uses a proof assistant for certain formal verification tasks, though the README does not elaborate on this.
The .github/ directory contains a CI workflow that runs a Dart check, consistent with the project maintaining some tooling despite being primarily a documentation repository.
The Feature Design Process and the Language Funnel
The README points to the language funnel project as the place to see which features are actively being worked on. The funnel is hosted as a GitHub Projects board under the dart-lang organization.
The doc/life_of_a_language_feature.md file documents the formal stages a feature passes through: problem exploration, proposal authorship, team review, prototype implementation, feedback collection from the broader Dart community, and final acceptance or rejection. This document is the definitive reference for contributors who want to propose a new feature.
The README describes the process as somewhat unstructured despite having defined stages. Features move at different speeds depending on complexity, team bandwidth, and community demand. The language team uses GitHub reactions to measure community interest in a proposed change: the README explicitly says that a thumbs-up reaction on an issue is more useful than a comment that only says the person wants the feature, because reactions aggregate demand in a way that many comments do not.
Any Dart user can open an issue to describe a problem or propose a language change. The README asks contributors to check for existing issues before opening new ones, because near-duplicate proposals split the discussion and reduce visibility for both. It also asks contributors to motivate proposals with real-world code examples rather than abstract descriptions, since concrete examples help the team and other community members understand the practical impact of a change.
The Official Language Specification
The specification/ directory contains the authoritative Dart language specification. The specification is maintained by Erik Ernst as a member of the language team. The README links to dart.dev/guides/language/spec as the published location of the official specification.
The specification is written in TeX, which is why the repository's primary language is listed as TeX. The TeX source is what lives in the repository; the rendered PDF or HTML is published separately on the official Dart site.
The specification describes the precise semantics of the language: what each construct means, what the type system rules are, and how programs are evaluated. It is a formal document intended for language implementors and advanced users who need precision, not a learning resource for new Dart developers. The Dart documentation site at dartlang.org provides the user-facing guides and tutorials.
Limitations and What This Repository Cannot Do
dart-lang/language does not accept bug reports about the Dart SDK, the Dart compiler, or the Flutter framework. Those belong in their respective repositories. Issues filed here about runtime behavior or SDK APIs are likely to be redirected or closed.
The repository contains no runnable code and no build artifacts. Reading the specification requires either compiling the TeX source or downloading the rendered version from the official Dart site. The repository does not include a Makefile or build script for the specification, so building it locally requires a TeX installation and some familiarity with the TeX toolchain.
The design process is public, but decisions rest with the language team. Community votes through issue reactions and comments inform the team's priorities but do not determine outcomes. A feature with significant community support may still be declined if it conflicts with language principles or implementation constraints. The README explicitly notes that features from other languages do not automatically translate well to Dart.
The repository also does not provide a timeline for any specific feature. The language funnel project shows what is being worked on but does not give scheduled release dates.
How This Compares to the TC39 Proposals Process for JavaScript
TC39 is the committee that governs the ECMAScript (JavaScript) standard, and its proposals repository serves a structurally similar function to dart-lang/language. Both repositories track proposed language changes through a staged process from initial idea to final inclusion in the specification.
The key difference is governance. TC39 is a multi-company standards body where representatives from browser vendors, runtimes, and platform companies vote on proposals. The Dart language process is controlled by a single team at Google. This means Dart language changes can move faster when the team agrees, but there is no external veto mechanism from other implementors.
For Dart developers, the practical implication is that a proposal accepted in dart-lang/language will eventually appear in the Dart SDK, since there is only one canonical implementation. For JavaScript, a TC39 proposal must also be implemented by each major browser engine before it is available in practice.
Maintenance Status and License
The repository is not archived. The last push was on 2026-09-18 and the project does not have GitHub releases. There are no release tags because the repository tracks ongoing design work rather than shipping discrete artifacts.
The repository includes a LICENSE file and a PATENTS file. The README links to both. The license terms apply to the content of the repository, including the specification source. Contributors who want to submit proposals should review these files before contributing substantive content.
The CI badge in the README runs a Dart workflow, indicating that the repository maintains at least some automated tooling despite being primarily a specification and governance resource.
Editorial conclusion
dart-lang/language is useful for Dart developers who want to understand why the language is the way it is, follow features in progress, or argue for a new language capability through the documented proposal process. It is not a starting point for learning Dart, compiling code, or filing SDK bugs. Before opening a new issue, search existing ones: the README warns that near-duplicate proposals divide attention and reduce both issues' visibility.
Frequently asked questions
What is the dart-lang/language repository used for?
It is the Dart team's repository for designing language features, tracking proposals at each stage of the design process, and maintaining the official Dart language specification. It is not for filing bugs against the Dart SDK or Flutter.
How can I propose a new Dart language feature?
Open an issue in the repository describing the problem you want solved, with real-world code examples. The README asks you to check for existing issues first to avoid near-duplicates, and to explain why the change would be right for Dart specifically.
Where is the official Dart language specification?
The specification source in TeX format lives in the specification/ directory of this repository. The rendered version is published at dart.dev/guides/language/spec and is maintained by Erik Ernst of the language team.
How do I follow the progress of a Dart language feature?
The language funnel is a GitHub Projects board linked from the README that shows features being actively worked on. Individual feature directories in working/ and accepted/ contain the detailed design documents.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/dart-lang-language)