mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-10-01 11:34:59 +01:00
Jon Meow
d031f3cdab
Co-authored by: chandlerc - Based on [PR 22](https://github.com/carbon-language/carbon-lang/pull/83) - [Idea topic](https://forums.carbon-lang.dev/t/proposal-for-an-incomplete-rough-high-level-overview-ready-for-early-feedback/52) - [RFC](https://forums.carbon-lang.dev/t/rfc-an-incomplete-early-and-in-progress-overview-of-the-language-design/73) - [Decision announcement](https://forums.carbon-lang.dev/t/accepted-an-incomplete-early-and-in-progress-overview-of-the-language-design/110) This proposal should be considered a starting point of the language design. It's not intended to be final; language details may change. This is intended to offer a reasonable starting point for: - Example code. - Conceptualizing Carbon at a high level. - Reasonable, but not necessarily final, approaches to features in README.md. - If any idea is obviously bad, we can clean it up here. This proposal is not intended to achieve: - A whole language design. - This is way too much work for a single proposal; this is a skeletal framework only. - As we work on feature-specific designs, we may decide to use other approaches. That's fine: we only need somewhere to start. - The summaries in README.md may be expected to change over time. - Feature-specific files aren't intended to be well-written or comprehensive. They are a quick jot of prior thoughts. - We want to avoid getting stuck on language details that we should consider more carefully regardless. If you're passionate about a feature, please feel free to start a new proposal for it. - Each and every aspect of the suggested overview should be subject to careful examination and justification before it becomes a settled plan of record. Chandler started this with https://github.com/carbon-language/carbon-lang/pull/22. I've taken it over with the following changes: - More of a directory hierarchy. - Trying to thin out the main file (now README.md) to lighter summaries of features. - Details/rationale/alternatives should be in feature-specific files. - Draft files are linked as references where added. For an example of how we may proceed with feature-specific designs, see https://github.com/carbon-language/carbon-lang/pull/80. In this structure: - docs/design/README.md mentions interoperability, with a light overview. - The light overview is not yet in https://github.com/carbon-language/carbon-lang/pull/80. - docs/design/interoperability/README.md goes into more depth on interoperability, covering key points of the approach. - Individual files in docs/design/interoperability/* go into more depth on interoperability. Simple designs may not have a subdirectory. All current feature-specific designs do not -- they may be moved later.
77 lines
2.4 KiB
Markdown
77 lines
2.4 KiB
Markdown
# Variables
|
|
|
|
<!--
|
|
Part of the Carbon Language project, under the Apache License v2.0 with LLVM
|
|
Exceptions. See /LICENSE for license information.
|
|
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
-->
|
|
|
|
## Table of contents
|
|
|
|
<!-- toc -->
|
|
|
|
- [TODO](#todo)
|
|
- [Overview](#overview)
|
|
- [Declaring constants](#declaring-constants)
|
|
- [Alternatives](#alternatives)
|
|
- [Declaring constants](#declaring-constants-1)
|
|
- [Global variables](#global-variables)
|
|
|
|
<!-- tocstop -->
|
|
|
|
## TODO
|
|
|
|
This is a skeletal design, added to support [the overview](README.md). It should
|
|
not be treated as accepted by the core team; rather, it is a placeholder until
|
|
we have more time to examine this detail. Please feel welcome to rewrite and
|
|
update as appropriate.
|
|
|
|
## Overview
|
|
|
|
Blocks introduce nested scopes and can contain local variable declarations that
|
|
work similarly to function parameters.
|
|
|
|
For example:
|
|
|
|
```
|
|
fn Foo() {
|
|
var Int: x = 42;
|
|
}
|
|
```
|
|
|
|
This introduces a local variable named `x` into the block's scope. It has the
|
|
type `Int` and is initialized with the value `42`. These variable declarations
|
|
(and function declarations) have a lot more power than what we're covering just
|
|
yet, but this gives you the basic idea.
|
|
|
|
While there can be global constants, there are no global variables.
|
|
|
|
### Declaring constants
|
|
|
|
Constants will use template-like syntax for declarations. For example, a simple
|
|
integer constant looks like:
|
|
|
|
```carbon
|
|
var Int:$$ MyVal = 42;
|
|
```
|
|
|
|
## Alternatives
|
|
|
|
### Declaring constants
|
|
|
|
There is other syntax that could be used for declaring constants. There are
|
|
serious problems with the use of `const` in C++ as part of the type system.
|
|
Another alternative is `let` from Swift, although there are some questions
|
|
around how intuitive it is for this to introduce a constant. Another candidate
|
|
is `val` from Kotlin. Another thing we need to contend with is the surprise of
|
|
const and reference (semantic) types. At present we are leaning towards the
|
|
tempalte-like syntax for consistency within Carbon.
|
|
|
|
### Global variables
|
|
|
|
We are exploring several different ideas for how to design less bug-prone
|
|
patterns to replace the important use cases programmers still have for global
|
|
variables. We may be unable to fully address them, at least for migrated code,
|
|
and be forced to add some limited form of global variables back. We may also
|
|
discover that their convenience outweighs any improvements afforded.
|