Require language design proposals to either update the design documents
to
reflect the proposed changes, or add "TODO" comments to mark where those
changes
will be needed, with links back to the proposal. This is intended to
ensure that
the design documentation accurately informs readers about the current
language
design, without excessively burdening the proposal process.
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
This proposal renames the syntax used to mark an overriding definition
of a virtual method from `impl fn` to `override fn` to avoid ambiguity:
besides indicating an overriding virtual function, it can be parsed as
an "impl" declaration when the construct following "impl" begins with a
lambda introduced by "fn".
Closes#5711
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Carbon is accelerating and adjusting its safety strategy, specifically
to flesh out its memory safety strategy and reflect simplifying
developments in the safety space.
This proposal replaces the previous directional safety strategy with a
new concrete and updated framework for the safety design. It includes a
specific framework for memory safety, simplified build modes, specific
"safety modes", and terminology.
This proposal also provides a _directional_ suggestion for temporal and
data-race safety specifically.
In addition to fully building out the above directional component, there
are several other aspects of our safety design that will follow in
subsequent proposals. The hope is to establish the initial framework
here.
---------
Co-authored-by: Dana Jansens <danakj@orodu.net>
Co-authored-by: josh11b <15258583+josh11b@users.noreply.github.com>
Co-authored-by: Mike Forster <michael@forster.pro>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
- A parameter binding can be marked `ref` instead of `var` or the
default. It will bind to reference argument expressions in the caller
and produces a reference expression in the callee.
- Unlike pointers, a `ref` binding can't be rebound to a different
object.
- This replaces `addr`, and is not restricted to the `self` parameter.
- A `ref` binding, like a value binding, can't be used in fields of
classes or structs.
- When calling functions, arguments to non-`self` `ref` parameters are
also marked with `ref`.
- The return of a function can optionally be marked `ref`, `val`, or
`var`. These control the category of the call expression invoking the
function, and how the return expression is returned.
- These may be mixed for functions returning tuple or struct forms.
- The address of a `ref` binding is `nocapture` and `noalias`.
- We mark parameters of a function that may be referenced by the return
value with `bound`.
---------
Co-authored-by: Josh L <josh11b@users.noreply.github.com>
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
In open discussion[1] we decided that "identical" rewrites would mean
that for a given LHS value, all RHS have the same value (after
evaluation), rather than requiring the RHS to all have the same
syntactic value. This means the following is valid, since the value of
`.Y` is known to be `()` while resolving the rewrite constraints of `T`.
So both rewrites of `.X` are resolved to `.X = ()`:
```
fn Identical(T:! I where .X = () and .X = .Y and .Y = ()) {}
```
The implementation of this clarification, along with test cases encoding
it, is done in https://github.com/carbon-language/carbon-lang/pull/5686.
Clarify this in the language design documents, and improve some other
clarity while we're there:
- The prose talks about a facet `T`, but the examples were using `A` as
its name. Change the facet to be `T`. This means changing the `.T`
associated constant (and `.U` and `.V`) to be `.X` (and `.Y` and `.Z`).
While doing this, use `I` for the interface name instead of `C`, which
we use more commonly for a class type name.
- Correct the comments in the cycle example that claim we find `.Y then
.Y* then .Y**`. In this example `.Y = .Z* and .Z = .Y*` which adds _two_
levels of pointers when evaluating `.Y`: `.Y => .Z* => (.Y*)* => .Y**`
[1]
https://docs.google.com/document/d/1Yt-i5AmF76LSvD4TrWRIAE_92kii6j5yFiW-S7ahzlg/edit?tab=t.0#heading=h.qti4vn50zwy
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: Carbon Infra Bot <carbon-external-infra@google.com>
This proposal codifies our preference for designs that support
"progressive
disclosure", meaning that programmers can ignore a given language
concept (or
even be unaware of it) until it is directly relevant to the task they're
doing.
Establish some guidance on using AI coding tools when contributing to
the Carbon
Language project. These tools have growing popularity and interest, and
it would
be good to have a clear and actively documented set of guidance for
folks
interested or already using them.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
We make 5 changes:
- Allow `require Self impls I` in an `interface` or `constraint` scope
to omit the `Self`, so it can be written `require impls I`.
- Rename `extend I` to `extend require impls I` in an `interface` or
`constraint` scope.
- Define `extend impl as I` and `extend final impl as I` in an
`interface` scope to copy the members of `I` and define an `impl` of `I`
in terms of the extending interface.
- Allow a non-final `impl` to overlap a final `impl` as long as it isn't
subsumed by the final `impl`. The final `impl` will be given priority on
the overlap.
- Allow `final` on a `match_first` block, used to declare overlapping
final impls.
These features work together to allow a form of interface extension
where:
- Types only need to `impl` the extending interface to also get an
`impl` of the extended interface.
- Multiple interfaces can extend the same interface.
- An interface can extend multiple interfaces.
---------
Co-authored-by: Josh L <josh11b@users.noreply.github.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: Dana Jansens <danakj@orodu.net>
Co-authored-by: Carbon Infra Bot <carbon-external-infra@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
This proposal re-affirms (with additional rationale) that a `var`
pattern
declares a durable complete object, and refines the terminology for
binding
patterns in a `var` pattern to be more explicit about the intended
semantics. It
also makes several other changes and clarifications to the semantics of
pattern
matching on objects:
- The storage for a variable pattern is initialized eagerly, rather than
being
deferred until the end of pattern matching.
- Any initializing expressions in the scrutinee of a `match` statement
are
materialized before matching the `case`s.
- An initializing expression can only initialize temporary storage or a
single
variable pattern, not a tuple/struct pattern or a subobject of a
variable
pattern. Removing this limitation is left as future work.
Finally, as a drive-by fix, it clarifies what parts of the `match`
design are
still placeholders.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
```
class C {
impl as I;
}
```
is redeclared
```
impl C.(as I)
```
for purposes of `match_first`/`impl_priority` blocks and definitions.
---------
Co-authored-by: Josh L <josh11b@users.noreply.github.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
I'm doing this separately from removing the explorer/ and installers/
directories so that it's easier to review the side-effects.
Note for the main README, I didn't think it was worth keeping a mention
of "used to have a prototype interpreter, now archived" versus focusing
on the existing toolchain (for "Currently, we have fleshed out").
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
The explorer is an archived codebase, without a plan to restart
development on it. The costs incurred by keeping it in the main git repo
can be alleviated by moving it to a new sibling repo, without
diminishing the usefulness of the explorer codebase for demonstrating
implementation of the carbon language design.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
(Note: this is *not* anything related to April 1st.)
Proposal to switch our week-to-week Carbon project development syncs to
be more
async.
- Start of each week, create a summary of what happened last week.
- Publish this in GitHub discussions for async reading and further
discussion.
- Stop our weekly meeting focused on these summaries.
- Start up a new discussion meetings every two months.
- Structure will be a 10-minutes-or-less update, and a "demo".
- Demo may be traditional: showcase a newly landed thing in Carbon.
- Or demo may showcase an interesting top-of-mind language design
discussion.
- Either way, goal will be to field lots of questions about the topic
and
have a good discussion everyone understands, not to reach some
"conclusion" or "decision".
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: Carbon Infra Bot <carbon-external-infra@google.com>
Allow qualified name lookup into classes and interfaces as soon as we
reach the `{` of the definition, rather than disallowing such lookups
until we reach the `}`.
Fix destructor syntax ambiguity by switching to `fn destroy` mirroring
standard function syntax. This is a purely syntactic change, maintaining
destructor semantics.
This comes from leads question #4999
---------
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
We propose to add `Core.Array(T, N)` as a library type in the `Core`
package. Since arrays are a very frequent type, we propose to privilege
use of this type by including it in the `prelude` library of the
package.
We would like to see a shorthand where `Core.Array` is automatically
imported into the file scope, and this proposal includes future work to
this effect.
We propose updating our milestones to accelerate design and
implementation of
memory safety in Carbon, and a roadmap for 2025 reflecting this change.
We also
provide a retrospective for 2024's progress.
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Introduce a principle that the Carbon language should not encroach on
the
developer's namespace. Satisfy this principle by making `Core` a
keyword.
---------
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Proposes a set of core features for declaring and implementing generic
variadic
functions.
A "pack expansion" is a syntactic unit beginning with `...`, which is a
kind of
compile-time loop over sequences called "packs". Packs are initialized
and
referred to using "pack bindings", which are marked with the `each`
keyword at
the point of declaration and the point of use.
The syntax and behavior of a pack expansion depends on its context, and
in some
cases by a keyword following the `...`:
- In a tuple literal expression (such as a function call argument list),
`...`
iteratively evaluates its operand expression, and treats the values as
successive elements of the tuple.
- `...and` and `...or` iteratively evaluate a boolean expression,
combining
the values using `and` and `or`, and ending the loop early if the
underlying
operator short-circuits.
- In a statement context, `...` iteratively executes a statement.
- In a tuple literal pattern (such as a function parameter list), `...`
iteratively matches the elements of the scrutinee tuple. In conjunction
with
pack bindings, this enables functions to take an arbitrary number of
arguments.
---------
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: josh11b <15258583+josh11b@users.noreply.github.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Carbon Infra Bot <carbon-external-infra@google.com>
The prettier pre-commit mirror is no longer supported
(https://github.com/pre-commit/mirrors-prettier). This switches to a
direct call, and updates to 3.3.3. And I'm now specifying types for it
to apply to, rather than letting it ignore unknown files; overall just
trying to separate out which linter sees what.
To comment on formatting changes:
- In most cases, seems to be getting confused by `[]` use in markdown
when it's not part of a link. This looks like a regression, but not one
we're broadly affected by.
- p0107.md - caught an issue with a malformed broken bad link which I've
tried to fix.
- p3720.md - looks like a fix.
Note, prettier has a 4.0.0 alpha release. As best as I could tell, that
only affected the .prettierrc.yaml processing. I changed the glob there
for forwards compatibility.
Establish a process for getting commit access. We will:
- Grant access based on a developer's commit history.
- Someone with commit access should nominate, and a contributor may ask.
- A lead will approve nominations. Only one lead is needed.
- Remove commit access once someone is idle for 6 months.
- "Idle" means no significant project activity on any of GitHub,
Discord,
or in meetings.
- Access removed due to being idle will be restored on request.
---------
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Update the operator precedence to achieve a few goals:
- Form operators into groups which behave similarly
- Make the group of operators ("top-level operators") that capture
everything to the right, like `if`...`then`...`else`, behave similarly
to the left, so that rearranging expressions won't change how they
group.
- Add the `where` operator, used to specify constraints on facet types,
to the precedence chart, to define how it interacts with other
operators.
- Make the operator precedence diagram prettier, so that it eventually
can be made into a poster that Carbon programmers can hang on their
walls.
---------
Co-authored-by: Josh L <josh11b@users.noreply.github.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Each entity is restricted to one, optional `extern` declaration. If
used, it must be imported by the defining library. The defining library
annotates the existence of an `extern` with the `has_extern` modifier.
---------
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Also a small pass on workflow names.
Note, I'm a little concerned that the test/nightly release/pre-commit
endpoints may be fragile. At the same time, it's also where it may be
most useful, to prevent network access by arbitrary test code. I think
this is imperfect, but maybe we can try it out and see if it's much of
an issue.
Note, the discord wiki action is currently broken, this should fix it.
Proposal for how Carbon version numbers work:
- A single version across language, standard library, compiler, linker,
etc.
- Semantic Versioning (SemVer) based
- Details of how SemVer criteria for major, minor, and patch should
apply to
Carbon
- Details of how we will operate before 1.0 and how this connects to
Carbon's
milestones
- Directional guidance for future work including post-1.0 versions, LTS
versions, and standardization
---------
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
The toolchain's [Semantic IR][semir] should start off modeling the full,
complex, and rich library-based and generic extension point semantics of
Carbon
without eliding any layers or rewrites for compile time efficiency. We
shouldn't
front-load elision or optimization when implementing the designs.
Once we have a full-fidelity implementation, we should work to build an
efficient elision, short-circuit, or common case simplification into the
design
itself sufficient to make the SemIR model efficient. Only if we cannot
find a
reasonable approach for that should we diverge the SemIR model to
optimize its
efficiency, and we should preserve full fidelity in an optional mode.
[semir]:
https://docs.google.com/document/d/1RRYMm42osyqhI2LyjrjockYCutQ5dOf8Abu50kTrkX0/edit?resourcekey=0-kHyqOESbOHmzZphUbtLrTw#heading=h.503m6lfcnmui
---------
Co-authored-by: josh11b <15258583+josh11b@users.noreply.github.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: Carbon Infra Bot <carbon-external-infra@google.com>
Require exact syntactic matching in redeclarations. Provide new
terminology for
redeclaration matching and agreement. Specify non-redeclaration rules
for the
other contexts where we require multiple declarations to match, such as
`impl`s
of `interfaces`, `impl`s of `virtual fn`s.
---------
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Carbon Infra Bot <carbon-external-infra@google.com>
In order to support exporting imported names, add `export import library
<library>` and `export <name reference>` syntax.
---------
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
The usual `pre-commit autoupdate --freeze && pre-commit run -a`
Cutting out a prettier update to v4.0.0-alpha.8 because I'm seeing it
consume all available CPU, basically hanging.
Update broken links to aid in following links while perusing the
documentation. Closes#3778
I don't imagine I got every one of these right. Some 404s may be
reported due to permissions.
Using the lychee command in #3778, only the following link is reported
as not found, but it's just a permission issue:
```
[proposals/p1367.md]:
✗ [404] https://github.com/carbon-language/carbon-lang/settings/access | Failed: Network error: Not Found
```
I tried to get it down to as few as possible, partially so that future
link scans won't run into repeat errors.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Carbon Infra Bot <carbon-external-infra@google.com>
- Add the `extern` keyword for forward declarations in libraries that
don't
provide the definition.
- Treat repeated forward declarations as redundant.
- Allow them when they prevent a dependence on an imported name.
- Clarify rules for when modifier keywords should be on forward
declarations
and definitions.
---------
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Add support for extracting elements of a tuple by their numerical index.
Also formally add the well-established basic syntactic and semantic
rules for
tuples, for which we have had leads issues but no proposal, into the
design.
We propose a roadmap for 2024 focused on a working Carbon toolchain that
supports Carbon ↔ C++ interop.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Proposal to focus implementation effort for the next 1-2 years on the
Carbon
toolchain instead of the explorer. This will impact the explorer in a
few ways:
- We will keep the explorer's code in place, building, and passing its
basic
tests. It can remain a good baseline for exploring Carbon's language
features.
- We won't prioritize expanding the explorer's coverage of Carbon
features or
other improvements -- it is good enough for what we need until the
toolchain
catches up.
- We will stop actively fuzzing and expanding test coverage for the
explorer.
- Eventually, when we want to resume work on the explorer, we'll
evaluate the
best platform to build on -- the current explorer codebase or on top of
the
toolchain's semantic IR.
Also tries to update the core readme and contributing docs to reflect
this.
Geoff RomerandRichard Smith
Jon Ross-PerkinsandDana Jansens
Elliott KaltandRichard Smith
Ivana Ivanovska
dongjinlong
cui fliter