I believe this reflects the intent, but the phrasing of "even if
`MyBaseClass` is not" implies that `MyBaseClass` _can_ be final in
`partial MyBaseClass`. Also, make clear it's allowed on `abstract`
classes, not only `base` (this seems explicitly intended from the
`MyAbstractClass` example around line 1482).
Includes proposals:
- #990
- #2188
- #2138
- #2200
- #2360
- #2760
- #2964
- #3162
Also tries to use more precise language when talking about:
- implementations, to avoid confusing `impl` declaration and definitions
with the `impls` operator used in `where` clauses, an issue brought up
in #2495 and #2483;
- "binding patterns", like `x: i32`, and "bindings" like `x`.
---------
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
First step in updating `docs/design/generics/details.md`. It
incorporates changes from proposals: #989#2138#2173#2200#2360#2964#3162 , but there are still more changes from those proposals to be
made.
It also switches away from suggesting static-dispatch witness tables,
and creates an appendix to describe that decision.
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
This reflects changes from a number of approved proposals:
- #920 : concrete statements about orphan and overlap in Carbon
- #2138 : "generic" -> "checked generic", "template" -> "template
generic"
- #2188 : binding patterns are forbidden in type position
- #2360 : "type", "facet type", "facet". Note: I am not using the term
"generic type" from #2360 since that meaning conflicts with the
generally accepted meaning of "generic type" of a type with a
compile-time parameter.
- #2760 / #2770 : internal/external impl -> extending impl
- #2964 : "symbolic constant" and "template constant"
---------
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
This includes:
- Syntax changes from this chart:
| Before | After |
| ------------------------------- | --------------------------------------- |
| `class D extends B { ... }` | `class D { extend base: B; ... }` |
| `external impl C as Sub;` | `impl C as Sub;` |
| `class C { impl as Sortable; }` | `class C { extend impl as Sortable; }` |
| `adapter A for C { ... }` | `class A { adapt C; ... }` |
| `adapter A extends C { ... }` | `class A { extend adapt C; ... }` |
| `interface I { impl as J; }` | `interface I { require Self impls J; }` |
| `interface I { extends J; }` | `interface I { extend J; }` |
- Dropping the syntax for conditionally implemented internal interfaces.
This does not include:
- terminology changes from #2760 ("internal" and "external")
- changes to code, such as explorer, toolchain, language grammars, or other tooling
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>
The toolchain link just needed a resourcekey.
The open discussion link may just not work because it was pre-go-public, so it points at a doc that we probably copied.
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>
Also make minor updates to the skeletal design in
docs/design/name_lookup.md following #2113, as there are no longer any prelude names that are made available to unqualified name lookup by default.
Add `type` to the keyword list in
docs/design/lexical_conventions/words.md, following #2360.
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>
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.
The most significant change here is that explorer now uses the chosen spelling
rather than the old `Bool` spelling. Also update a few documentation examples
and some skeletal design docs to use the chosen spelling.
Operators rewrite to calls of specific operator interface functions, so you overload an operator for a type by implementing an interface for it. There is a `like` operator for defining a set if implementations for supporting implicit conversions more conveniently.
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Define initialization, assignment, comparison, and implicit conversion between data classes with different field orders and/or types.
Implements the decision made in #710 .
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Add support for nominal (or "named") classes with encapsulation. Inheritance will be in a later proposal. Here is an example of the proposed syntax:
```
class Circle {
fn Create(c: Point, r: f32) -> Self {
return {.center = c, .radius = r};
}
fn Diameter[me: Self]() -> f32 {
return me.radius * 2;
}
fn Expand[addr me: Self*](distance: f32);
private var center: Point;
private var radius: f32;
}
fn Circle.Expand[addr me: Self*](distance: f32) {
me->radius += distance;
}
```
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
This proposal defines the very basics of `class` types, primarily focused on:
- use cases including: data classes, encapsulated types, inheritance with and without `virtual`, interfaces as base classes, and mixins for code reuse;
- anonymous data types for called _structural data classes_ or _struct types_. Struct literals are used to initialize class values and ad-hoc parameter and return types with named components; and
- future work, including the provisional syntax already in use for features that have not been decided.
The intent is to both make some small incremental progress and get agreement on direction. As such it doesn't include things like nominal types, methods, access control, inheritance, etc.
It proposes this struct type and literal syntax:
```
var p: {.x: Int, .y: Int} = {.x = 0, .y = 1};
```
Note that it uses commas (`,`) between fields instead of semicolons (`;`), and no introducer for types or literal values.
Incorporates decisions from #665 , #653 , #651
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Jon Ross-Perkins
Dana Jansens
Geoff Romerandjosh11b
Richard Smith
Adrien Leravat
Josh Soref
Ryan Russell
Jon Meowandjosh11b