Make the preamble of simple programs more ergonomic, by removing the
`package Main` from the main package and removing the `package`
declaration
entirely from the main source file. Imports within a single package no
longer
need to, and are not permitted to, specify the package name.
Partially covers #2001 / #1136.
Covers #1869.
Supersedes #2265.
Addresses design idea #2323.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
The Carbon Project relied on the three leads to handle conduct concerns initially as it bootstrapped its community team and expertise. We now have an active and effective community lead and team of moderators. Our community lead has worked to train and ramp up a new and independent conduct team.
This proposal both provides an overview of the process and hands off conduct handling to the new team! Going forward, we expect routine updates to the conduct team to happen without full proposals as they allow trained folks to rotate in and out of this difficult but essential role on the project.
Last but not least, making these changes uncovered a restriction in the Code of
Conduct itself that we expect to be problematic to adhere to going forward.
While well intentioned, it has a bunch of unanticipated effects that made both
current and new conduct teams want to remove it. A related section has had its
wording strengthened to try and address the underlying motivation at least
partially.
Most of this content comes from @CelineausBerlin with some additions and edits from myself and the other leads as we worked toward building the new CoC team.
Co-authored-by: Céline Dedaj <CelineausBerlin@users.noreply.github.com>
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Kate Gregory <kate@Gregcons.com>
Put character literals in single quotes, like `'a'`. Character literals work
like numeric literals:
- Every different literal value has its own type.
- The bit width is determined by the type of the variable the literal is
assigned to, not the literal itself. Follows the plan from #1934.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Allow an `impl` to overlap with a `final impl` if they agree on the overlap. Agreement is defined as all values comparing equal, and functions never comparing equal. Implements the decision in question-for-leads issue #1077.
Provide a clear definition of our goals for the 0.1 Carbon language, and a
concrete feature-set that is expected to satisfy these goals.
The high level goal proposed for the 0.1 language is to reach an evaluation-MVP
(Minimal Viable Product): it should be sufficiently complete to evaluate its
suitability specifically with respect to fitness as a C++ successor language.
The features proposed for 0.1 language in turn focus on C++ interoperability and
a minimal subset of foundational aspects of the language.
Beyond the language itself, the other project features and milestones proposed
focus on enabling evaluation of the language design and interoperating with C++
in practice.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: jonmeow <jperkins@google.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
This proposal replaces the termination algorithm for `impl` selection. The previous algorithm relied on a recursion limit, which is counter to [our goal for predictability](/docs/design/generics/goals.md#predictability).
The replacement is to terminate if any `impl` declaration depends transitively on itself with a "strict superset" type as one of its parameters.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: Satakshi Garg <56358125+satakshigarg@users.noreply.github.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Use the keyword `impls` instead of `is` when writing a `where` constraint that a type variable needs to implement an interface or named constraint.
What was previously (provisionally) written:
```
fn Sort[T:! Container where .ElementType is Ordered](x: T*);
```
will now be written:
```
fn Sort[T:! Container where .ElementType impls Ordered](x: T*);
```
---------
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Statements, declarations, and definitions will terminate with either a semicolon
(`;`) or a close curly brace (`}`). Semicolons are never optional.
For example, with a semicolon, `x = x + 2;`. With a close curly brace,
`for ( ... ) { ... }`, or `class C { ...}`.
This does not affect any approved proposal; rather, it makes an important
assumption explicit.
Based on lead decision #1924Fixes#2002
Split the `where A == B` constraint in two: `where .A = B` produces a new
constraint from an old one, where the value of `.A` in the new constraint is
known and eagerly rewritten to `B`, and `where A == B`, which does not cause
`A` and `B` to be considered as identical by language rules but does permit
implicit (no-op) conversion between them.
This aims to provide an efficiently-computable and human-understandable type
equality rule, with type canonicalization and therefore transitive type
equality, without sacrificing too much in the way of ergonomics and without
sacrificing determinism, while still providing the full power of a general type
constraint system in a less ergonomic form.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Assignment is permitted only as a complete statement, not as a subexpression.
Assignment and compound assignment syntax follow C++ in all other respects.
Pre-increment is provided. Post-increment is not. Uses of all of these operators
are translated into calls to interface members.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
This was discussed in person with at least two of the leads while
drafting the text, but sadly it did not finish being typed into the
document.
Just amending the proposal text for the future as I don't think it
substantively changes the conclusions.
Thanks to @geoffromer for noticing this!
Define a "type" to be a value of type `type`. Contexts expecting a type perform an implicit conversion to `type`. Values like `()` and `(i32, i32)` and `{}` are no longer types, but instead implicitly convert to `type`. Values of interface or constraint type (now called "facets") are similarly not formally types but implicitly convert to `type`.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Carbon has been using a `me: Self` or `addr me: Self*` deduced parameter to mark a function as a method as decided in #494 and implemented in #722 . This does not match existing languages, and so this proposal switches `me` to `self` to match Python, Rust, and Swift.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Require `impl as` constraints in an `interface` or `constraint` definition to mention `Self` implicitly or explicitly. Require `where` clauses to refer to `.Self` directly, or through a designator like `.Foo`.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Add template generics, with optional constraints but no [SFINAE](https://en.cppreference.com/w/cpp/language/sfinae), to Carbon. Template generics allows the compiler postpone type checking of expressions dependent on a template parameter until the function is called and the value of that parameter is known.
Example usage:
```carbon
fn Identity[template T:! Type](x: T) -> T {
return x;
}
```
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Allow unqualified name lookup in multiple situations:
- For classes and interfaces, whether inside the class scope or within an
out-of-line function definition.
- For namespaces, when the namespace is used in a declaration.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Adds support for subscripting using the conventional square-bracket syntax, with support for both array-like and slice-like semantics.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Remove a confusing mention of a specific version of C++ (C++17) from the
interoperability goals.
Expand the content of the goals to make it clear that we have a moving and
ongoing target of C++ as it continues to evolve. Also emphasize that we will
prioritize among the different features during Carbon's development based on how
they impact the overall project.
However, this intends to preserve the fact that there may exist long-tail or
corner-case features in C++ that never end up with high quality or exhaustive
support in our interop story simply because their impact on Carbon users is
sufficiently small that it doesn't justify the cost.
Fixes#1587
Provides a documented cadence, publishing target, and template for Code of Conduct and moderation transparency reports.
Based on the initial proposal draft from @CelineausBerlin.
Co-authored-by: Céline Dedaj <CelineausBerlin@users.noreply.github.com>
chandlerc had originally added these and previously expressed being okay with removing them. They've just proven too complex to be applied; it needs to be easier for people to want to do it.
This proposal specifies how unused pattern bindings are written in the Carbon programming language. This is a more general problem statement of "how do users specify unused function parameters" as function parameter declarations are a more specific form of pattern
Related issue #1996
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Change terminology from "generics" and "templates" to "checked generics" and "template generics". Afterwards, "generics" will be an umbrella term that include templates.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
This proposal aims to add a literal syntax for fixed-sized numeric types: integers, unsigned integers, and floating-point numbers.
Fixes#1998
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
A number of smaller changes grouped together in one proposal:
- Make `Self` a keyword.
- Clarify that `Self` refers to the current type in a base class and in impl declarations.
- Clarify when `.Self` is legal, and what type it has.
- Also specify that `where` is not an associative operator.
It is currently difficult to see the status of Carbon explorer and where effort
is needed. We propose creating a AreWeYet-styled dashboard to address this.
Reading through extensive problem and background documentation before seeing
what is being proposed is tedious for a reader. An abstract section at the
beginning of a document that provides a succinct summary helps a lot. We
propose adding such a section to our proposal template.
Use `"` for simple string literals and `'''` for block string literals.
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
This is being done because Projects v1 requires repo write access, a serious limitation for letting people use it. Projects v2 isn't a great option because it lacks event support. Labels are pretty stable in GitHub, so this switches to that.
Note this assumes we're fine renaming "decision: accepted" -> "proposal accepted", etc. There are two reasons for this:
1) To make it clear that this is a proposal-specific label, versus something like an issue for leads label.
2) Removing the colon because it was causing trouble with yaml syntax.
This also adds the "proposal draft" label, mainly to complete the taxonomy.
I was considering whether this should be a proposal itself, but it feels like maybe it's not necessary because it's a fairly low-key infrastructure change, and I'm not sure how much people were relying on the project board anyways.
I tested this in a personal repo, basically just poking at https://github.com/jonmeow/test/pull/2
Krishna Agarwal
Josh Soref
FirstSS