2026-02-17— Last Week in Carbon

[josh11b]

Updates on leads issues

• Decisions
  • (none)
• New issues
  • #6735 What signatures are acceptable for Run? How are argc and argv exposed?
  • #6739 Should we have a way to perform C++ default initialization?
• Active discussions
  • (none)

Updates on proposals

• Decisions
  • #6716 Move toolchain alternatives to proposals
  • #6699 Diagnostic sorting
  • #6710 char redesign
  • #6641 Clang IRGen in Carbon
  • #5545 Expression form basics
• New RFC proposals
  • (none)
• Active discussions
  • (none)

Updates on moderation across our community spaces (Discord and GitHub)

• Conduct team update:
  • Transparency report for Q4 2025: done
• Moderation interventions last week:
  • A Discord member was banned after joining only to promote their services/look for a job
  • We also discussed when we want to speak as a team or as individual contributors
• Activity in the past week:
  • 10 authors have pushed 24 commits to trunk.
  • On trunk, 410 files have changed and there have been 8,543 additions and 4,130 deletions
  • We merged 24 PRs, opened 12 additional PRs, closed 1 issue, and opened 6 new issues.

Activity on toolchain

• #toolchain CLI flags
• 02-10 Source locations in monomorphization errors
• #toolchain 02-10 representation of form parameters
• 02-10 Mixing different phase parameters, and form-generics that can result in multiple runtime parameters
• #toolchain #6722 Inst order preconditions
• #toolchain Form pattern matching
• #toolchain Inst formatter fixes
• #toolchain Caching generated functions
• #toolchain DeduceImplArguments can have side effects
• #toolchain Making impl lookup of Destroy no longer construct a function when there's a symbolic argument
• #interop range-based for loop interop with C++ ranges
• #llvm Difficulties getting libraries from compiler-rt in bazel-ified runtimes
  • toolchains_llvm_bootstrapped may have some overlap
• #generics-and-templates 02-10 Issues with bad diagnostics
• #naming Rationalizing "eval" vs "exec"
• Toolchain release notes
• PRs:
  • tests #6705 #6711 #6737
  • compile-time function eval in #6694
  • diagnostics in #6718
  • docs in #6719
  • Destroy in #6731 #6732
  • forms and categories in #6734 #6730
  • accessing C++ variables in #6748 #6743
  • vscode syntax highlighting in #6543
  • dependencies in #6749
  • others in #6708 #6707 #6720 #6723 #6724 #6733 #6721 #6738 #6722
• New contributors:
  • @KarthikSBhattar made their first contribution in #6707

Activity on memory safety

• 02-10
  • Introducing a separate alias set for each parameter, which is contained inside ^default, instead of being ^default directly, to allow speaking about each parameter’s places independently.
  • Thinking of ^ a “place of” operator
  • C++ can leak the address of const refs, which can be constructed from values, allowing C++ to leak the address of a value. For safety we can assume a returned pointer does not come from any input const ref. Use [[lifetimebound]] to learn that a const ref can contribute to an output, and thus change how it can be called with values vs refs.
  • Value bindings are part of a ^value alias set which overlaps but is different from ^default. Value returns by default reference ^(value, default).
• #safety New doc: Carbon memory safety comparison to Rust. Please help keep it up to date.
  • Trying to keep it focused on our safety story in particular, not other language design differences.

Other active discussions

These include Discord Chat, GitHub Discussions, or open discussion sessions.

• #syntax Continued discussion of dropping : and type from self: Self, and/or moving it to the explicit parameter list.
  • Converging on two possible models:
    • The Carbon status quo: Methods are different from functions. Methods can't be called directly (like X.M(...)) and x.(X.F) is invalid if F is not a method. In this model self belongs in the implicit param list.
    • Methods are only special in simple member access. Methods can be called like functions, with self as the first argument. x.(X.F) performs partial application. In this model self belongs in the explicit param list.
  • 02-10 #syntax Converging on declaring class methods with class fn F(...), but don't see a good way to omit self in methods.
• #naming Continued discussion of what to name the non-owning array type, and whether we can use [T] syntax for it.
• #functions How to capture qualified names
• #strategy Discord is rolling out age verification, but it looks like the we don't use the features that require it.
• #getting-started Why doesn't changing the implementation of Less to "int.greater" break any tests?
• #contributing-help How to organize the tests for C++ interop integer types.
• #typesystem Noting a couple loose ends from the expression forms proposal.
• #syntax Shorthand for discarding multiple elements in tuple destructuring?
  • Struct syntax continues to be a readability issue, but probably not ripe to address now.
• #pattern-matching Should the destructors for unused and _ bindings inside var run immediately or at the end of the scope?
  • End of scope. Maybe we need a separate syntax to discard immediately?
  • Does this also apply to _ in structs?
• #general-design What might defer look like in Carbon?
• #general-design How far can we go with unifying structs and tuples?
• #proposals-prs-and-process How to merge old PR?
  • Our repo always squashes on merge automatically, so you don't need to worry about it.
  • If there are conflicts, usually better to resolve them by merging rather than rebasing.
• #general-design Noting some low-priority thoughts on allowing break to take an argument inside block.
  • Probably better to put low-priority thoughts in a doc.
• #infra New tool for diffing/testing VSCode syntax highlighting. Could try it on our Carbon highlighting?
  • Note that VSCode Carbon highlighting should eventually move to the LSP.
• #evolution Does Carbon interop target C++17 or C++20?
  • Mainly C++20, but more broadly, whatever versions are in common use and feasible to support.
• #contributing-help Having trouble importing standard library headers.
  • Looks like file_test doesn't support that yet. We can fix it, but should use it sparingly to minimize test overhead.
• #infra How to work around "CHECK condition is always true" errors when static_assert isn't a valid alternative?
• #naming Could we say "value freezing" instead of "value acquisition"?
  • Should we say "object expression" instead of "reference expression"?
• #typesystem Some discussion of hypothetical ~ move operator. Could it also be used to mark discarded patterns?
• #error-handling Would it be possible to make all functions that return errors be generic on the error type?

RSS Feed for "Last Week in Carbon" here