docs/project/milestones.md
As Carbon progresses, we want to have some common long-term milestones that we orient our work around. The annual roadmap provides a specific and immediate set of priorities for the year, but we want successive years to point in a coherent direction with meaningful end goals. Milestones should typically be long-term, spanning more than a year, and have some functional motivation.
We also assign version numbers to our initial milestones to make them easy to refer to and incorporate into various versioning schemes.
The first milestone is also the most concrete -- it is the MVP for C++ users and developers to begin evaluating Carbon seriously. We want to keep this milestone as minimal as we can while still enabling a sufficient initial round of evaluation.
From the perspective of outcomes, our goals for the 0.1 language are centered around what we expect evaluations to be able to include:
These are focused on the core necessary features for us to reach a successful 0.1 language that can address our goals. Some of these features are required directly by the above goals, others are required due to dependencies or interactions with the directly required features. However, we don't try to cover all of the features in full granularity here. There will be many minor components that are necessary for these to hold together but are not directly addressed. In general, unless something is explicitly described as partial or having exceptions, everything covered by that entry should be expected in the 0.1 language.
Another important point is that this doesn't commit Carbon to any particular design for any of these bullet points. Instead, it just means that the Carbon design must have something that addresses each of these bullet points. That might be to add the named design to Carbon, but it equally might be a clear statement that Carbon will not include this design but use some other language features to address its use cases and when rewriting C++ code using that feature into Carbon.
swap, etc)
into synthetic Carbon interfaces for common cases (likely based on
heuristics)switchstd::variant and
std::optional interopif let in Rust) and negative (let else in Rust)
combined match control flow and variable declaration-fno-except C++ dialects and standard C++ dialectsstd::expected, something roughly compatible with
std::expected, C++ exceptions, etc.Note: we expect to heavily leverage the C++ standard library by way of interop for the vast majority of what is needed in Carbon initially. As a consequence, this is a surprisingly more minimal area than the language features.
bool, iN, fN)There are a few important components of the overarching Carbon project that need to be completed as part of 0.1 beyond language features:
The second milestone already concretely in mind is reaching a level of feature-completeness. The completeness metric here is based around the features necessary to credibly address the existing needs of C++ users and developers interested in moving to Carbon, and so will be heavily driven by either features already in use in C++ or necessary features to make moving off of C++ a viable tradeoff. Ultimately, we need this milestone to be sufficiently feature complete that users can complete their evaluation of Carbon. The language will continue to evolve and grow features beyond this, but at this point there shouldn't be any feature gaps that are problematic for the initial target audience coming from C++, and we should be able to finalize the Carbon experiment with this feature set.
That said, this is about as concrete as we can get for a milestone that remains years in the future. The full scope of requirements for this milestone will be defined as we complete 0.1 and begin getting feedback on it. Currently, we just call out specific features that we are actively deferring until at least 0.2 but without being listed somewhere could cause confusion.
Specifically, why not address them earlier in 0.1? Or if they can be deferred why not defer them further?
Coroutines and async programming are large and complex topics to introduce into the language. From watching C++, Rust, Swift, Kotlin, and many other languages working in this space, we have a strong belief that trying to add these to the 0.1 language would significantly increase the amount of work and likely delay when we reach that milestone. Also, given the recency of coroutines being added to C++, we expect evaluators to be able to reason about their absence and still accomplish most of the evaluation of Carbon without issue.
However, we also expect that as coroutines start to be widely adopted in C++, they will become an essential feature of the language that would be extremely difficult to give up when moving to Carbon. So we expect coroutines to be a necessary feature for us to effectively decide that the Carbon experiment is a success and begin planning large-scale adoption and migration.
Even less concrete is the milestone that marks Carbon no longer being an experiment, but if successful, a usable language. Currently this is speculatively called 1.0 but even that is highly subject to change as we approach. Again, we simply call out features here that we do expect to have in a 1.0 milestone, but want to explicitly defer beyond the 0.2 milestone.