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>
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>
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>
One implication here is that both proposals/README.md and the website should use basically the same format for their proposal lists. Another subtle change is that the website sidebar was previously sorted by *filename*, and is now sorted by *title*, which seems better because it's something that readers can see.
Enumerating why files change:
- gen_sidebar.py is the centerpiece, with a couple helpful functions for re-use elsewhere
- Delete the old sidebar html includes
- Modify the Makefile to handle gen_sidebar.py reasonably well (let's be honest... I'm not great at Makefiles)
- Move proposal listing out to its own file (proposals.py) for re-use
- Add a few PYTHONPATH things + `__init__.py` files to get modules importing correctly (may be a better way at this, I've hit a wall though).
* first draft of proposal for basic syntax
* rename proposal
* formating
* fixing typos
* precendence and associativity
* minor edit
* added abstract syntax
* some revisions based on feedback from meeting today
* optional return type
* oops, not optional for function declarations
* replacing abbreviations with full names
* name changes
* Update proposals/p0162.md
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
* removed = from precedence table
* for fun decl, back to optional return type, shorthand for void return
* more fiddling with return types
* change base case of statement_list to empty
* added pattern non-terminal
* added expression style function definitions
* change && to and, || to or
* change and to have equal precedence
* updating text to match grammar, fix typo in grammar regarding pattern
* adding trailing comma thing to tuples
* removed 'alt' keyword, not necessary
* flipped expression and pattern
* added period for named arguments and documented the reason
* change alternative syntax to use tuple instead of expression
* comment about abstract syntax
* code block language annotations
* added alternative designs, some cleanup for pre-commit
* spell checking
* filled out the TOC
* minor edits
* minor edit
* trying to fix pre-commit error
* changes from pre-commit?
* changes based on meeting today
* describe alternatives regarding methods
* more rationale in discussion of alternatives
* addressing comments
* typo fix, added text about next steps
* removed *, changed a ! to not
* Update proposals/p0162.md
Co-authored-by: Geoff Romer <gromer@google.com>
* edits from feedback
* pre-commit
* added second reason for period in field initializer
* added executable semantics, fixed misunderstanding regarding associativity
* update README
* added a paragraph about tuples and tuple types
* Update proposals/p0162.md
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
* addressing comments from josh11b
* Update executable-semantics/README.md
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
* link to implicit parameters in generics proposal
* added non-terminal for designator as per geoffromer's suggestion
* changed handling of tuples in function call and similar places as per josh11b and zygoloid
* moving code to separate PR
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
When writing C++ code for Carbon, we want to keep all of our code consistent,
easy to learn, and help avoid spending undue code review time arguing about
the same core style and idiomatic issues.
This adopts the Google C++ style guide as a baseline, and then makes minimal,
focused additions and adjustments to it to suit the needs of Carbon.
Co-authored-by: Thomas Köppe <tkoeppe@google.com>
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: austern <austern@google.com>
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
Factored out of the Lexical Conventions proposal (https://github.com/carbon-language/carbon-lang/pull/173). This proposal covers only the encoding aspect: Carbon text is Unicode, source files are encoded in UTF-8, and we will follow the Unicode Consortium's recommendations to the extent that they make sense to us.
* Decision for proposal #42 (Create code review guidelines)
This is a recreation of PR #137 that got stuck in git merge hell.
* Results of running pre-commit
josh11bandRichard Smith
Richard SmithandChandler Carruth
Matthew Riley
Sidney HummertandChandler Carruth
Bryce Adelstein Lelbach aka wash
