This implements decision #565 to use `T:! Type` to declare generic parameters, and `template T:! Type` for template parameters.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Establish a principle that understanding the meaning and performance should not depend on expensive context, and explain what makes context expensive.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Require braces, never optional, particularly in control flow like `if`/`else`.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Propose the decision from #542, noting implementation from #563
Also integrates some of #339 into `variables.md` because that's actually how this started, looking for a proposal reference for #542
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
To talk about generics as a programming language feature, you need a lot of
specialized terminology. We need to agree on the words we are using and their
meaning before we can meaningfully talk about the design of the feature itself.
There a number of problems a glossary solves:
Not everyone knows every term, so having a single place to look them up will
improve the ease of understanding, ease of contributing, and accessibility
of the project.
There may not be widespread agreement on the meaning of some terms. In
particular, individual programming languages tend to assign very specific
meanings to terms used within their ecosystem.
Some terms may be used in multiple ways, but we only use the term with one
specific meaning.
Some terms are our invention and we need to introduce them.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
The "generics" feature of Carbon is a large design effort that needs to be broken up into manageable steps. The first thing we need is a high-level goals document. The goals here reflect the desirable properties that we have discovered as part of considering several alternative generics designs:
- Use cases:
- Generic programming
- Upgrade path from C++ abstract interfaces
- Dependency injection
- Generics instead of open overloading and ADL
- Performance
- Better compiler experience
- Encapsulation
- Predictability
- Dispatch control
- Upgrade path from templates
- Coherence
- No novel name lookup
- Learn from others
- Interfaces are nominal
- Interop and evolution
- Bridge for C++ customization points
Goals are summarized in [this presentation](https://docs.google.com/presentation/d/12yGyu5Pvdag7CJp-_yLVkmbhyvuRIilBTNlkO0LKaHo/edit?usp=sharing&resourcekey=0-JB9yrUO4-6J8-zzGhnIyNg).
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: Matthew Riley <mdriley@gmail.com>
Co-authored-by: austern <austern@google.com>
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
A Carbon function that needs to report recoverable failures should return a sum type whose alternatives represent the success case and failure cases, such as Optional(T), Result(T, Error), or Bool. The function's successful return
value, and any metadata about the failure, should be embedded in the alternatives of the sum type, rather than reported by way of output parameters or other side channels. Carbon's design will prioritize making this form of error handling efficient and ergonomic.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
In support of #426. There's still a little bit of surrounding framework that expects these decision files, but I'm trying to split out changes.
Note I'm dropping affirming/abstaining, as well as the accepted date -- I'd be happy to copy-paste decisions into comments on PRs if it'd be helpful, but I thought maybe we could drop those from the repo given they aren't asked for in on new proposals. If we change our minds, we can always look at git history too.
This proposal revamps Carbon's governance structure and evolution
process to try to make it significantly more efficient, friendly,
welcoming, and effective. Proposal process and RFCs are structured much
closer to a traditional code review. The review is driven by a Carbon
lead, although they may delegate some aspects and anyone in the
community is encouraged to participate. Resolving issues in order to
make a decision is handled with GitHub issues and through consensus
among a very small, focused team of leads. It also tries to encourage
explicitly showing interest and enthusiasm in Carbon proposals.
See the proposal text for all the details!
Many thanks to @KateGregory, @jonmeow, @mmdriley, and @zygoloid for
their early ideas and suggestions that ended leading to the direction of
this proposal. I also want to specifically thank them for challenging my
initial direction. 🙂
My plan is to update documentation, `CODEOWNERS`, and other
implementation details in follow-up PRs, but I'm happy to roll any of
them into this one where useful.
Landing as this was accepted by the core team, and reviewed by both a
Carbon lead and review manager so is covered in both processes.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
* Allow configuration of start point.
* Use git switch --create.
* Maybe fix string type.
* Fix wrong flag.
* Add --dry_run flag.
* Not sure if this is needed.
* Dry run should be safe even with uncommitted changes.
* Remove side effects with --dry_run.
* Checkpoint progress.
* Make `dry_run` parameter optional so tests pass.
* Implement suggestions from code review.
* Checkpoint progress.
* Remove new dry_run_pr_number option.
* Rename --start_point to --branch_start_point.
This document tries to lay out a high-level roadmap for Carbon in 2021
following the [roadmap process](/docs/project/roadmap_process.md).
Co-authored-by: Dave Abrahams <dabrahams@google.com>
PR #280 committed the decision for #199. #199 had the proposal and no decision
and modified `README.md`. #280 had a decision but no proposal, and *didn't*
update `README.md`. However, in a tree with both the proposal *and* its
decision, another modification is necessary.
Since only one PR modified `README.md`, there wasn't a merge conflict that
required a rebase. And since there was no rebase, each PR ran its own CI
blissfully unaware of the other.
For now, committing the results of `pre-commit run --all-files` on trunk.
Later, will look into ways to make the proposal+decision workflow less likely
to break trunk.
Create a team to oversee the implementation of Carbon. This team is
responsible for code reviews as well as handling any implementation-specific
decisions.
Originally, it was suggested to call this a "toolchain" team. During
discussion, it became clear that the scope wasn't easily limited to
implementation efforts that were necessarily part of the toolchain. There are
many different aspects of implementation, and we anticipate code sharing
between them that make it unhelpful to try to separate these. Instead, this
team is chartered with broadly covering all of the implementation concerns in
Carbon. If someone is concerned that an issue is larger than that, perhaps
impacting the design of the language, the project, or the community, the
standard process already provides for easy escalation to the core team.
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: austern <austern@google.com>
Co-authored-by: Geoff Romer <gromer@google.com>
- Shift some things around to adjust to being in bazel.
- Add separate build/serve/publish scripts for use by bazel (not set up for direct execution, but bazel requires +x).
- Fix some tests I noticed not running unittest.main as a result of the switch.
- Move md files into filegroups for build reuse.
- Disable automatic site publishing (now `bazel run //website/jekyll:publish`)
Site publishing seems like it'd be too much trouble to keep automated... The C++ toolchain essentially needs to be set up due to the repo config, along with syncing the LLVM submodules, etc. That seems a bit annoying to do on each run of the publish-docs action, and not something I really want to maintain. If we get a CI, we can focus on it more there, but this feels like it'd just be a one-off to maintain as a github workflow.
josh11bandRichard Smith
Richard SmithandChandler Carruth
Matthew Riley
Sidney Hummert