carbon-lang

carbon-lang copied to clipboard

Flesh out and solidify the design around values, variables, and pointers. Explicitly discuss the use cases of references in C++ and propose specific approaches to address those use cases.

This is something that we've been discussing across the team for a long time, and while there are definitely still challenges in this space we will need to address going forward, I want to try to codify where we are at and provide for a few fundamentals that haven't really been spelled out previously.

That said, I've been staring at this document for far too long in a draft, and so I may be missing parts that are confusing or need work, so any help from folks to make this a coherent story is definitely appreciated. The current structure and wording is heavily informed by several reviews and suggestions from @zygoloid, @josh11b, and @wolffg with much appreciation. =]

Some core examples of the consequence of this proposal:

• Using let where we currently use var to declare a locally scoped immutable view of a value:

  let index: i32 = 42;
  

• Specifying the expected semantics of parameters to by default be these immutable views of values like let. These should behave like C++ const references but allowing copies under as-if.

• Specifying that var creates an L-value and binds names to it.

• Defining that var patterns are allowed to nest within let to mark a part of a pattern as an L-value:

  let (x: i64, var y: i64) = (1, 2);
  
  // Ok to mutate `y`:
  y += F();
  

  When the entire declaration is a var the let can be omitted.

  This works with function parameters as well to mark consuming an input into a locally mutable L-value:

  fn RegisterName(var name: String) {
    // `name` is a local L-value in this function and can be mutated.
  }
  

• Implementing operators by rewriting into method calls through an interface, which can then use [addr me: Self*] to implicitly obtain a mutable pointer to an object for mutating operators.

• Providing user-defined pointer-like types and the implementation of both the *-operator and -> member access in terms of rewriting into member calls through an interface and then forming L-values.

• Providing indexed access through rewrites into method calls as well.

Beyond these use cases, thread-safe interfaces and more complex lifetime based dispatch are deferred for future work.

See the proposal for details here, and looking forward to feedback!

We triage inactive PRs and issues in order to make it easier to find active work. If this PR should remain active, please comment or remove the inactive label. This PR is labeled inactive because the last activity was over 90 days ago. This PR will be closed and archived after 14 additional days without activity.

We triage inactive PRs and issues in order to make it easier to find active work. If this PR should remain active or becomes active again, please reopen it. This PR was closed and archived because there has been no new activity in the 14 days since the inactive label was added.

Reopening since I think the intent is to pick this back up.

We triage inactive PRs and issues in order to make it easier to find active work. If this PR should remain active, please comment or remove the inactive label. This PR is labeled inactive because the last activity was over 90 days ago. This PR will be closed and archived after 14 additional days without activity.

We triage inactive PRs and issues in order to make it easier to find active work. If this PR should remain active or becomes active again, please reopen it. This PR was closed and archived because there has been no new activity in the 14 days since the inactive label was added.

Migrated to https://github.com/carbon-language/carbon-lang/pull/2006