carbon-lang/proposals/p0051.md

Goals

Pull request

Table of contents

• Problem
• Background
• Proposal
  • Including success criteria
• Alternatives
  • Change priority of interoperability and migration
  • Address project goals differently
    • Status quo
    • Completely remove the community priority from this document
    • Add project goals to the priority list
    • Merge project goals and language goals

Problem

We want to have clear goals for the Carbon project, to both establish and document where we expect Carbon to be headed. These are aspirational goals, and we will try our best to achieve all of them. The documented goals should make it easier for potential users to determine whether Carbon is an appropriate fit for them.

Background

Carbon's goals are heavily based on "Goals and priorities for C++". Many thanks to the authors and contributors for helping us formulate our goals and priorities.

This proposal was drafted in Docs.

Proposal

The proposed goals are encapsulated in the goals changes.

Including success criteria

The goals are currently a series of rough goals, with no specific metrics to measure them by. We've discussed adding metrics, and decided not to include them in the goals; the expectation is that they'll be added separately as a principle.

This proposal includes success criteria covering:

• Platforms
• Migration tooling

It should be expected that more will be added in the future.

Alternatives

Change priority of interoperability and migration

Right now, interoperability/migration is priority #7, indicating that when trade-offs are necessary, interoperability is likely to suffer. At least some parties believe it should be somewhere in the top 3 priorities, perhaps #1. Overall, we believe a consensus can be formed around keeping interoperability/migration as #7, so long as there are clear minimum expectations for interoperability.

Part of the priority conflict may be an interpretation that there will only rarely be compromises between goals, irrespective of the priority of interoperability. For example, considering the readability of C++ interoperability syntax, it could be viewed in two ways:

1. An edge-case syntax that can be avoided in most code, thus not significantly affecting the readability goal.
2. A readability issue that risks making all code less readable, representing the interoperability goal as subverting the readability goal, in which case either interoperability must be higher priority than readability, or we must have no interoperability.

While the proposers prefer the first interpretation, the second all-or-nothing interpretation may be what's leading to the desire of treating interoperability as a higher priority.

Overall, we would present the pros and cons as:

Pros:

• There is a consensus that interoperability is critical. Making it the top goal emphasizes that.

Cons:

• While interoperability is critical, the same is true of other goals; this isn't enough to determine priority.
• There are trade-offs between goals where there is already a consensus that inteoperability will be diminished in favor of other goals, and there aren't as many clear cases in the other direction.
  • Taken to extremes, making interoperability and migration a higher priority than evolution would suggest that Carbon should start with C++ and incrementally evolve from that base. We have observed areas where C++ has had trouble evolving, and Carbon would risk getting stuck on similar local maxima in order to avoid breaking existing code.

For example of where trade-offs may be seen right now:

• Carbon's set of primitive types won't match C++'s list; we currently expect multiple C++ types to map to single Carbon types. This could be considered a conflict with multiple priorities:
  • #2: Carbon's leaning for fewer types should make evolution of the language easier.
  • #3: Carbon code will be easier to read and understand with fewer types.
• When considering Int vs int, Carbon's plans do not mirror C++. This could be considered a conflict with multiple priorities:
  • #1: Carbon's primary types, such as Int, should be allowed to replace C++-specified overflow behaviors with alternatives that are higher performance.
  • #3: Avoiding platform-specific types should make it easier to understand how could will function on various platforms.
  • #4: Carbon's plan for Int trapping where C++ would overflow should make code safety easier.
• We expect platform support priorities to differ between C/C++ and Carbon. This is a conflict with Carbon's #6 priority, which focuses support on modern over legacy platforms.
• C++'s preprocessor macros will be replaced by metaprogramming in Carbon. It's not clear what migration of code using macros will look like, but some will likely be expanded by automation. This could be considered a conflict with multiple priorities:
  • #2: Structured metaprogramming should make it easier to evolve software.
  • #3: Metaprogramming should be easier to read than preprocessor macros.
• Templates have been argued as only being added for interoperability/migration, and that we could only have generics without that goal. This is not considered a conflict between goal priorities.
  • This could be considered a conflict with priority #3, because templates are hard to read and understand. However, templates don't constrain other parts of the language. While they may have readability or other problems, they aren't core or required in the way that other elements are, including primitive types.

Address project goals differently

A concern was raised that, while the "Governance and evolution" doc calls for all decisions to be justified by goals, there was no clear goal to justify the existence of things like a code of conduct. Similarly, if performance is the highest priority, then one might decide that retaining a performance expert may take priority over addressing their bad behavior.

To address this issue, project goals were added. They are not explicitly part of the numeric priority list. However, while we expect a ranking of language goals in order to weigh tradeoffs in the language design, we see project goals as orthogonal to language design.

Status quo

The project goals could be addressed as-is in the proposal.

Completely remove the community priority from this document

We could completely remove the project goals from this document.

Pros:

• Allows this to be the "language goals" document.

Cons:

• Creates additional documents that need to be understood to parse language goals.
• Makes for less clear prioritization of community, increasing ambiguity on how community vs language design conflicts can be resolved.

Add project goals to the priority list

We could make the project goals part of the priority list.

Pros:

• Makes the ordering unambiguous.

Cons:

• Makes what's currently a numerated list of language design goals less design-focused.
• Prevents saying trivial things like "performance is our top priority".
  • Unless community isn't the top priority, re-creating the conflict risk that led to the creating of these project goals.

Merge project goals and language goals

Originally, we only had one goals and priorities section. We could re-merge project goals and language goals.

Pros:

• Makes the document shorter and more concise.
• Tooling can already be considered a priority under "Code that is easy to read, understand, and write", and is explicitly mentioned as part of that goal.

Cons:

• Previous setup raised objections over why the community goal wasn't part of the priority list.