2026-03-30 — Last Week in Carbon

[josh11b]

Updates on leads issues

• Active discussions
  • #6830 Should import Cpp inline be part of the declaration list rather than the preamble?
    • 03-26 Decided to use inline keyword, as inline Cpp ’’’...’’’
    • Did not yet decide if there is a trailing semicolon.
  • #6931 Update to the syntax for class members: functions, methods, fields, etc.
    • 03-26 #naming Discussion of keyword use for non-instance vars and methods in classes and interfaces: class, static, global, shared.
    • Also considering non-instance vars inside functions.
  • #6932 Should we move away from :! syntax for generics and templates?
    • Discussion mostly about defaults. Whether they should be context-dependent. Whether they should be type-dependent.

Updates on proposals

• Decisions
  • #6902 Identification of a named constraint during definition
    • A facet type is now partially identified as soon as its referenced named constraints are declared. A partially identified facet type can be used to provide a (symbolic) witness, but can not be used as the target for an impl lookup or conversion. This allows require decls to use prior require decls inside a named constraint, as was intended by the design.

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

• Conduct team updates:
  • none
• Moderation interventions last week:
  • WIP: interview round of TypeScript community leaders so we can learn from their journey so far
  • WIP: Input for the moderation team about how to balance open and appropriate communication in our spaces
  • WIP: individual mentoring/coaching within the team
• Activity in the past week:
  • 11 authors have pushed 39 commits to trunk and 40 commits to all branches.
  • On trunk, 547 files have changed and there have been 15,797 additions and 12,556 deletions
  • We merged 39 PRs, opened 8 additional PRs, closed 1 issue, and opened no new issue.

Activity on toolchain

• #toolchain 03-24 #6953 Numbering of lines and insts in SemIR
  • Decision: instead of changing line numbers in SemIR, update Carbon's VSCode extension to help show the matching line number
• 03-26 Representing call parameter list in a form generics
• #generics-and-templates How to represent the Call parameter list of a form-generic function
• #toolchain :? in terms of template-like actions
• #toolchain Maybe we should give up typed nodes for inst locations
• #toolchain PerformThunkCall
• #toolchain diagnostics
• PRs:
  • insts in #6938 #6942 #6963 #6972 #6973 #6980
  • runtimes in #6946
  • parameter patterns in #6930
  • diagnostics in #6956 #6975
  • nested namespace from C++ in #6940
  • class declaration from C++ in #6955
  • in-place return in #6954
  • default constructible C++ types in #6962
  • named constraints in #6915 #6974 #6979
  • calling functions from C++ in #6967 #6984
  • thunks in #6965
  • #toolchain remove unused parameters in #6971
  • specifics with errors in #6982
  • #pattern-matching parens in patterns in #6976
  • expression patterns in #6977
  • vscode extension in #6834 #6957 #6959 #6960
  • Remove jonmeow in #6964 #6966
  • AI agents in #6969 #6985 #6986
  • docs #6981
  • deps in #6944 #6968
  • others in #6948 #6978

Activity on memory safety

• 03-23 Want heuristics to allow strict Carbon to call C++ when it’s reasonable. Avoid wrappers when possible. Allow wrapper Carbon types for C++ types to express safety constraints.
• 03-24
  • C++ function is unsafe for strict Carbon if any type in its signature contains an unowned pointer, which translates into an external place group parameter.
  • Wrap C++ type to change relationships of pointers, such as to declare ownership, which removes an alias set parameter.
  • Assuming reference parameter/return is okay for strict Carbon to call without unsafe.
  • Default inferred aliasing for C++ functions.
  • A std::unique_ptr wrapper would not have an external place group parameter on the class. So it will have to mark the reset method as unsafe because it’s taking ownership of an external pointer, and that relationship is lost once it’s stored in the class. Wrote some sample code for a UniquePtr wrapper.
  • We need a default effect of invalidating owned memory when calling C++ from strict Carbon, just as when moving into a C++ function.
  • Permissive Carbon can call any C++ without unsafe.
  • Permissive mode tracks invalidation but only creates errors when 100% confident of the invalidation (the entire alias set is invalidated), rather than “may have been” invalidated (some part of the alias set is invalidated).
• 03-24
  • We could use a C++ annotation (GSL owner?) to declare a C++ type owns its pointer instead of requiring a Carbon wrapper.
  • Owned data is invalidated by calls to C++ that can access it, unless const.
  • Carbon can assume C++ won’t const_cast an input into an output. It’s like an “unsafe” in the C++ code.
  • Allow const& to alias by default. Mutable ref params must be disjoint.
  • Expect refs are not passed across thread, captured, can’t be null, won’t be deleted.
  • Treat this like a reference not a pointer. delete this is rare.
  • Assume captures of inputs only happens into outputs with non-owning pointers.
• #safety New safety unit 44 on calling C++ functions from Carbon

Other active discussions

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

• #general-design No package private yet
• #generics-and-templates Named constraints partial identification proposal
• #interop reverse interop from C

RSS Feed for "Last Week in Carbon" here