2025-11-17— Last Week in Carbon

[josh11b]

Updates on leads issues

• Decisions
  • #6166 C++ Interop: How should C++ operators interact with Carbon operator interfaces?
    • Use Carbon rules to prioritize Carbon impls, and C++ rules to prioritize C++ overloads.
    • When there are both, apply Carbon rules, and pick C++ candidate if better than all Carbon candidates, or pick Carbon candidate if better than all C++ candidates.
    • Should allow both languages to specialize each other naturally, while avoiding ambiguity.
  • #4908 Should it be valid to define a package named r#Core?
    • Yes. We don't want to disallow any names as raw identifiers.
• New issues
  • (none)
• Active discussions
  • #6324 Ambiguity in ref grammar
    • Leads think it's important to use the same keyword in parameter list and callsite, because it generalizes better if we also want to annotate other kinds of parameters like inout.
    • Suggest modeling ref as an operator in the toolchain that changes the category to "ref tagged expression", and reject that in most contexts but give it special meaning in the places we choose.
  • #2152 What should we call integer types with mod-2^N arithmetic?
    • We need to keep uN type family for C++ interop, but there are also important non-interop use cases so we probably shouldn't put it in CppInterop namespace. Not much motivation for a separate modular arithmetic type.
    • Rust uN types panic on overflow by default; there are separate types like Wrapping<u32> when wrapping is desired. Not sure if we want to do that in Carbon.
    • But note the question is about how to name these types, not whether they should exist and/or be interop-only.
  • #6291 C++ Interop: How to map reference types (T&) vs. pointer types (T*)?
    • If we have a special Core.Cpp.Ref(T) type, should it behave like a reference, or just be a tag for uses like template arguments?
  • Linked name of issue: discussion snippet

Updates on proposals

• Decisions
  • (none)
• New RFC proposals
  • #6357 C++ Interop: Mapping pointer types
    • Proposes zero-overhead mapping for C++ pointer types and std::nullptr_t into Carbon.
    • Some discussion about whether to map void* to something like u8* or byte*.
  • #6358 C++ Interop: API importing and semantics
    • Builds on direction of #6254 by providing explicit C++ import syntax.
• Active discussions
  • #6331 Add import Cpp; for C++ built-in entities
    • Leads favor making Cpp a keyword.
      • That means we'll need a separate Core.CppCompat namespace for things like Long32.

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

• Moderation and conduct teams are still the same size, available in theory from UTC-7 until UTC-5.5: 10 trained members altogether + community lead (hands-off trainer, coach, guide)
  • WIP: Prepare resources to help close our skill gaps as identified by the team itself
  • PENDING: update moderator intervention documentation
• Activity in the past week:
  • 3 spamming incidents on Discord since last week, one involving spam posted to all channels. Messages were deleted and the users were banned.
  • New contributor!? 🎉
  • In the last 7 days in our repo: 10 authors pushed 32 commits to trunk, we changed 583 files with 13,047 additions and 7,580 deletions, which means we merged 32 PRs, opened 13 PRs, we closed 2 issues and opened 1 new one.

Activity on toolchain

• #toolchain Answering build process questions
• #toolchain How to import requirements
• #toolchain Issues with dependencies from a generic on a specific
• #toolchain #6364 Making types for C++ compat private?
• #toolchain Attributes on C++ function declarations that reference parameter names?
• #toolchain #6329 String indexing
• #toolchain Confusing comment on GetUnattachedConstant
• #toolchain #6372 Copyability and naming of a synchronization primitive
• 11-13
  • How to model the type component of a form in SemIR?
  • Discussion of #6364, specifically the idea of making CppCompat names private.
• #generics-and-templates 11-14 Problems with Identify and complete facet types as needed for p5168 #6369's model of RequireImpls.
  • Completing is about name lookup, and so is only concerned about requirements that are extended, but needs those to be complete as well
  • Identifying is about determining a list of interface specifics and their corresponding Self types, and only cares about extending for purposes of determining that an impl is implementing a single interface, and so requires a Self type.
  • These two concepts are different enough that we are going to break the dependency between them
• PRs:
  • RE2 example in #6337
  • C++ preprocessor macros in #6326 #6338
  • require in #6318 #6321 #6348 #6344
  • ref in #6312 #6359
  • import in #6350 #6352 #6355 #6356 #6354
  • C++ Interop: support for nullptr and nullptr_t. by @zygoloid in #6353
  • Import C++ ref parameters in #6360
  • facet types and named constraints in #6345 #6365 #6367 #6368 #6369
  • C++ Interop: long integer types in #6364 #6363
  • other C++ interop in #6278
  • synchronization in #6372
  • dependencies in #6147 #6378
  • others in #6349 #6351 #6374
• New contributors:
  • @neundorf made their first contribution in #6278

Activity on C++ interop

• 11-11 For operators impl, we should do C++ lookup in `CollectCandidateImplsForQuery()` and build `TypeStructure` for candidates.
• 11-11 Could we solve the string_view problem with extension methods?
  • Several open questions around extension methods
  • For now there's a workaround: write free adapter functions as inline C++ snippets.
  • Toilsome. OK for a few core library types, but when users start needing this capability, we'll need a language feature.
• #interop Discussed contributing to linking with C++ libraries, calling C++ functions and mangling.

Activity on memory safety

• #safety Should we give up on having the [[free]] effect?
  • We need something like it to distinguish mutations that reshape a container and ones that don't.
• #safety Does it make sense to model async as an effect?
  • So far we've avoided letting effects affect run time behavior.
  • Async fits better with something like control flow effects, which is a different paradigm.
  • If we do that, it probably belongs in the return form.
• #safety Link to Google Security blog post on Rust in Android.
• 11-13 discussion of the [[call]] effect
  • Need to be more explicit about things like captures
  • Might need to annotate call with constraints on what the call can do.
    • Or model them as "associated effects"
  • Want to avoid it becoming a description of what the function can do. Instead, try to make it a set of capabilities that the function has access to.
• #safety On modeling as capabilities instead of effects, see paper Designing with Static Capabilities and Effects.
  • Confirms that capabilities are simpler, and modeling as effects means tracking alias relationships.
  • Several potentially useful/interesting ideas.

Other active discussions

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

• #infra Issue reporting was turned off for the Fizzbot repository. Fixed now.
• 11-10 Interface and named constraint sometimes behave differently despite identical bodies.
• 11-10 Satisfying interface requirements for a definition
• 11-11 Clarifying the guidance in #6342 on ref ambiguity
• 11-11 Considering options about extension methods and using them to represent C++ APIs on types shared with Carbon
  • Follow-on to discussion from last week on #interop
  • A number of options and decisions. Easy to workaround for now, so not urgent to decide.
• #generics-and-templates Trouble with () due to TupleLiteral not having a constant value.
• #typesystem Trouble getting user-defined arithmetic to work
  • The code as written required an exact type match.
  • Can fix that with impl forall [T:! Core.ImplicitAs(i32)] as Core.AddWith(T) ...
  • Language design has a like operator to simplify that, but not yet implemented.
  • Pending proposal #5389 would change that.
• #infra //toolchain/driver:runtimes_cache_test is flaky.
  • Reported as issue #6174.
  • Could be caused by the OS reusing inodes.
• #strategy Draft of Carbon Copy Add the firebase site framework to carbon-lang. #9 out for review.
• #llvm PR #6147 updating LLVM is ready for another review pass.
• #build-help Looking for help keeping Bazel memory usage under control.
• #syntax How to call C functions like getenv and rand from Carbon, and access argc/argv?
  • See examples/re2_playground (e.g. here) for examples of calling into C++.
  • No support for argc/argv yet.

RSS Feed for "Last Week in Carbon" here