carbon-lang/proposals/p0829.md

One way principle

Pull request

Table of contents

• Problem
• Proposal
• Alternatives considered
  • Provide multiple ways of doing a given thing

Problem

We have repeatedly run into cases where we could offer equivalent functionality multiple ways.

Proposal

Add a principle noting the preference is to only provide one way of doing things.

Alternatives considered

Provide multiple ways of doing a given thing

Carbon could focus on providing a lower bar for overlapping functionality, encouraging overlapping syntax. This could be considered as similar to Perl's "There is more than one way to do it.". Overlapping syntax should still receive some scrutiny, but use-cases with small marginal benefits might be considered sufficient to create divergent syntax.

For example:

• For matching C++ legacy:
  • We might include for (;;).
  • We might re-add support for optional braces on if and similar.
  • We might support class and struct with their C++-equivalent default visibility rules.
  • We might support both and and &&, 0xa and 0XA, etc.
• We might make ; optional, as there's precedent in modern languages to do so.
• Both templates and generics might be embraced with feature parity such that both should be good solutions for generic programming problems, as much as possible.

It's worth noting Perl also has a related motto of "There is more than one way to do it, but sometimes consistency is not a bad thing either." It's best to avoid interpreting this alternative to the extreme: for example, this is not encouraging providing all of extensible, extendable, and extendible as equivalent keywords, as that is divergence with very minimal benefit (particularly extendable versus extendible).

Advantages:

• More likely that developers will find syntax that they like.
• Can make it easier to migrate code because we can actively support a C++-like dialect in addition to a more Carbon-centric dialect.

Disadvantages:

• Developers would either accept personal styles, or create more style guides.
  • Either can be considered a language dialect, whether at the personal or organizational level.
• Increases the difficulty of building syntax parsing and typo correction in the language, as there are more options that need to be corrected between, multiple of which may be valid in a given context.

We are declining this alternative because we value the language simplicity provided by minimizing overlap of features.