This proposal:
- Adds support for interfaces requiring other types than `Self` to implement interfaces, as in:
```
interface IntLike {
impl i32 as As(Self);
// ...
}
```
- Defines requirements on how to satisfy those requirements that have a `where` clause.
- Extends `observe` declarations to include saying a type implements an interface, so code can provide a proof instead of the compiler having to perform a recursive search.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
A rephrasing was suggested on https://github.com/carbon-language/carbon-lang/pull/1188#discussion_r851416370 because "explorer" alone could be hard to parse; I'm suggesting just replacing with "Carbon explorer" to get precision without changing phrasing, as well as rephrasing "Executable semantic" as "Carbon explorer" (which... the former *may* have meant "executable semantics", but the difference in pluralization made it vague, so I'm not sure this is right -- but it also didn't explain _where_, so "executable semantics" seems the right reading)
Co-authored-by: Geoff Romer <gromer@google.com>
Encourage reviewers to merge when they feel okay doing so. Let reviewers make
that choice. Let authors say they'll merge themselves.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Add concrete design for interfaces for comparison.
Rename interfaces for arithmetic following current thinking in #1058.
Update rules for mixed-type comparisons for data classes following #710.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Right now, the text is disallowing appeals to logic (which are persuasive methods, per the linked wikipedia article). Consensus seems to be that this is unintentional.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
This proposal has three main contributions:
- Types with generic parameters have an identity that consists of the types names plus the values of those parameters.
- The parameters of a type may be deduced from a function's argument.
- Types with generic parameters do not support specialization. Instead, a type can delegate to an interface to opt in to allowing specific customization points.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Given repeated concerns about C++ interop priorities: taking a pass at being more direct about priorities and tradeoffs.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Allow interfaces and implementations to be forward declared.
```
// Forward declare interface `F`
interface F;
class C {
// Forward declare `C` implements `F`
impl as F;
}
// Definitions corresponding to forward declarations
interface F { ... }
impl C as F { ... }
```
To allow members of interfaces with default definitions to be forward declared, prefix them with the keyword `default`, following #1082.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
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>
Add support for arithmetic operators:
- Unary `+`.
- Binary `+`, `-`, `*`, `/`, `%`.
Specify their behavior for integer and floating-point types. Signed integer overflow is a programming error, handled in various ways. Unsigned integer overflow is specified as wrapping around, intended for hashing / crypto / PRNG use cases.
Co-authored-by: jonmeow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Provide an initial rough structure for the specification so we can add things
as they are decided.
Split the specification into a language and a library section. In the language
section, use one file per broad area of functionality. Divide the language up
based on the intended layering of the language design.
Roadmap updates for 2022. Key goals:
* Reach the point where the first draft of the core language design is complete, with some test programs and an approximate implementation in executable semantics.
* Go public, and improve public participation.
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
This proposal addresses the question of whether we should perform a fully top-down compilation (like in C), a mostly top-down compilation (like in C++), or whether we should allow information from later in the same source file to be used in earlier program constructs (like in Rust, Swift, Java, C#, Haskell, and so on).
The proposed direction is:
- Entities declared later in the same source file cannot be used earlier; top-down semantics apply everywhere.
- As an exception, class member function bodies are parsed as if they appeared after the class.
- Forward declarations can be used to separate interface from implementation and to allow entities to be used before they are defined.
- The behavior of the program is nonetheless required to be the same as if we had a globally-consistent rule: it's always a hard error to depend on any information that is not known or that is provided later.
Support for member access expressions with syntax `container.member`, covering cases such as:
* `object.field`
* `object.method(args)`
* `package.namespace.class.member`
* `object.(interface.member)`
* `object.(class.member)`
... and so on. Includes the rule for template name lookup as decided in #949.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
This is intended to be a more iterative edit to the chart:
- Adding `if` and struct literals, since it came up in arithmetic.
- Adding links to address a comment of mine about wanting references
- Rephrasing slightly to reduce the implication that it's only for operators (particularly since I don't think we want to call `if` an operator)
- Shifting operators below because similar
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Moves common script logic into utils.py (not a great name, but couldn't come up with better). This is in particular to make the buildifier.py script really trivial, allowing that pre-commit to be easily added. However, scripts have also been diverging on how we find bazel, so I'm trying to unify that.
The advantage of reimplementing buildifier's pre-commit is that (a) we can now run buildifier server-side, and (b) we can stop advising installing it manually. Then the only Linux-specific package manager is Cargo, which is only used for watchman, which is optional -- so stop highlighting Linux-specific package managers in the tool instructions.
This proposal introduces a conditional operator of the form:
```
if cond then value1 else value2
```
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
I was doing this for #851 initially, but I think #438 and #826 hadn't made it in (possibly intentionally due to #851? I don't recall).
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Change the syntax for setting the associated constants and types in an interface implementation for a type from using `let` declarations as in:
```
class Vector(T:! Type) {
impl as Iterable {
let ElementType:! Type = T;
...
}
}
```
to using `where` clauses as in:
```
class Vector(T:! Type) {
impl as Iterable where .ElementType = T {
...
}
}
```
This is an attempt to simplify by removing redundancy, improve consistency by removing a use of `let` that was different than other examples, and better support forward declaration that a type implements an interface while retaining the information needed for type checking.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Allowing interfaces to define default values for its associated entities. This:
- Helps with evolution by reducing the changes needed to add new members to an interface.
- Reduces boilerplate when some value is more common than others.
- Addresses the gap between the minimum necessary for a type to provide the desired functionality of an interface and the breadth of API that user's desire.
As an alternative, final values can be provided instead, which can't be overridden, but are more predictable for users and may avoid dynamic dispatch overhead in some cases.
Example:
```
// Interface parameter has a default of `Self`
interface Add(Right:! Type = Self) {
// `AddWith` *always* equals `Right`
final let AddWith:! Type = Right;
// `Result` has a default of `Self`
let Result:! Type = Self;
fn DoAdd[me: Self](right: Right) -> Result;
}
impl String as Add() {
// Right == AddWith == Result == Self == String
fn DoAdd[me: Self](right: Self) -> Self;
}
```
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
This is a proposal to adopt interfaces as the single static open extension mechanism for things like selecting how operators are implemented for types.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
There were some concerns about facet types leaking out of generic code in return types. Some initial fixes for this were done in [PR #900](https://github.com/carbon-language/carbon-lang/pull/900), but there remain concerns, for example when associated types are involved.
In particular, given an interface method with return type using an associated type, as in:
```
interface Deref {
let Result:! Type;
fn DoDeref[me: Self]() -> Result;
}
class IntHandle {
impl as Deref {
let Result:! Type = i32;
fn DoDeref[me: Self]() -> Result { ... }
}
}
```
Since `Result` has type `Type`, we had the problem that `IntHandle.DoDeref` would have to return `i32 as Type`, instead of the desired `i32`.
We also think we can simplify the model by eliminating the facet type concept and syntax.
This proposal removes facet types, introduces archetypes in their place, clarifies how associated types work outside of a generic function, and specifies how a generic `let` statement in a function body works.
Co-authored-by: Wolff Dobson <wolffg@users.noreply.github.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
josh11b
Richard Smith
Jon MeowandGeoff Romer
Richard Smithandjosh11b