2025-10-06 — Last Week in Carbon

[josh11b]

News

• Chandler's RustConf 2025 talk "Memory Safety Everywhere with Both Rust and Carbon" now available on YouTube (slides)

Updates on leads issues

• Decisions
  • (none)
• New issues
  • #6166: C++ Interop: How should C++ operators interact with Carbon operator interfaces?
  • #6161: How does partial interact with destruction?
    • #toolchain for now not going to support destruction of partial types
  • #6160: How should array initializers be constrained?
• Active discussions
  • (none)

Updates on proposals

• Decisions
  • #5606: Keep design documents current
    • Approved & merged!
    • As the PR is written, the TODOs (or full documentation updates) are added. Checking for documentation updates is part of the normal review cycle.
• New RFC proposals
  • (none)
• Active discussions
  • #5545: Expression form basics
    • After some more iteration, in good shape except for waiting on resolution of #6160
  • #5389: Generic across forms
    • Some iteration

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)
  • PENDING: summary of interviews of C# community leaders about C#’s community journey for moderation team
  • PENDING: transparency report for Q4 2025
  • WIP: Moderation skill self-assessment summary, and creation of corresponding resources, internal training or coaching sessions for moderation and conduct team members.
• Activity in the past week:
  • Spam was deleted (7 messages), reported to Discord, and the corresponding user account was banned
  • In the last 7 days in our repo: 10 authors pushed 23 commits to trunk, we changed 495 files with 12,752 additions and 29,423 deletions, we merged 23 PRs, opened 5 PRs, we closed 2 issues and opened 5 new ones.

Activity on toolchain

• #generics-and-templates Ran into a bug with nesting names inside generics.
• #generics-and-templates Figured out complicated problem with SymbolicBindingType.
• 10-02 Debugging generic import
• #toolchain Directory reorganization?
• #toolchain #6162 Bug on function signature mismatch
• PRs:
  • C++ interop in #6122 #6138 #6101 #6149 #6151 #6152 #6150 #6156
  • #toolchain destruction in #6125 #6144 #6119
  • IndexWith in #6127
  • facet values in #6113 #6146 #6119 #6157 #6158
  • runtimes in #6133
  • reduce test sensitivity in #6145
  • docs in #5890
  • internal checks in #5997
  • #toolchain interface error recovery in #6155
  • infra in #6153 #6154
• New contributors:
  • @evoxtorm made their first contribution in #5890

Activity on C++ interop

• 09-30 #interop Operators support: Integrating into impl lookup and what to do with the relational operators and OrderedWith interface require leads questions.
• 09-30 Nullable pointers support requires more work on Carbon optional support.
• 09-30 #interop Next potential features: Reference return types, extern C functions, pointer to member types, void*, static data members, triggering initialization for inline variables.
• #interop Where have we documented the relationship between str and std::string_view?
  • Nowhere yet. It was discussed at the summit but needs to be turned into a leads issue.

Activity on memory safety

• 09-29 Discussion about Safety Unit No. 2: Flow-sensitive Alias Sets
• 10-02 When inferring alias sets in a loop with conditionals, is the resulting set of paths regular?
• #safety Is it feasible to keep safety information out of types?
  • That would prevent you from doing things like parameterizing a type by an alias set.
  • Even if not needed in theory, the ergonomics are much better.
  • Container element types need alias sets, because they can’t be distinguished otherwise.
  • 09-29 Is there a situation where the static analysis by itself can't prove safety, but by having the user express an invariant that all modules can verify holds, can then prove safety?
  • Types vs. constraints expanded in Safety Unit No. 4.
  • Container use case discussed in Safety Unit No. 5.
  • Maybe we can get the best of both?
  • Constraints outside types may be especially valuable for interop, where sometimes we can’t add safety info to C++ types.
• #safety Safety Unit No. 3, on the flow-checking big picture.
  • This may run into scaling problems, as discussed on No. 2.
  • The issue isn’t a matter of optimization, it’s the fundamental computational complexity of the analysis.
• #safety Safety Unit No. 6 on another hard problem: singly-linked lists.
  • If we had a transitively exclusive pointer (like &mut T in Rust) we wouldn’t need effects, but that invariant could be hard to maintain without borrows.
    • “Ownership types” may be useful here.
  • Shape analysis could be relevant here
  • We still need a way to apply unchecked safety assertions to code that the compiler can’t prove safe.
  • This is a famously challenging problem in Rust, which solves it with the paradigm of a safe API wrapping unsafe code.
• #safety Could Carbon be the “language of the future” for safety-critical applications?
  • We’re focusing on migrating C++ code to safety. Other languages are probably better if you’re writing green-field code.
  • Is memory-safety important for safety-critical software?

Other active discussions

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

• 09-29, #infra New Discord bot for reminding you about Carbon code reviews
  • Only accessible to contributors for now.
  • See #review-pings for details, or type /fizz help anywhere on our Discord server (your message and its response will not be visible to others in the channel).
  • We set up a new channel #bot-testing if you want a place to message bots without accidentally disrupting other channels.
  • 10-02 Away handling
• #typesystem Having a hard time getting an inheritance hierarchy to support both as patterns and “designated patterns” without metaprogramming or a lot of duplicated code.
  • (continued) Sketched attempt to do so in a doc.
  • Without new ideas it seems like we’ll have to choose one or the other. Leaning toward as patterns.
  • Maybe this should be a leads issue?
• #typesystem How to spell the type of .Bar(42)?
  • .Bar(Core.IntLiteral) as type seems natural, but we can’t say it in a where clause.
  • Something like Core.Designator(“Bar”, 42) could work, but might leak too much.
  • Maybe designator(Bar, 42) or designator Bar(42)?
  • BTW it seems likely we’ll need designator forms as well as designator types.
• #generics-and-templates Could we extend Generic across forms #5389’s definition of alias to support alias (... each A) = B?
  • Especially valuable because some code can only be written in terms of each A, not in terms of B.
  • Probably fine, but #5389 is already large, so this should probably be separate.
• #contributing-help Any simple tasks for new contributors?
  • No unclaimed good-first-issue issues in GitHub.
  • For now the toolchain tasks doc might be the best bet.
• #infra Trying out GitHub code review settings for the project (see #6153, #6154)
  • Lets people mark themselves busy and not get auto-assigned code reviews.
  • Currently using round-robin, not trying to load-balance.
  • Caused some notification noise, but team notifications are now off.
• #typesystem Have we discussed letting a class extend another type like case A extend B?
  • Yes, in proposal #3802, currently on hold because use cases weren’t high priority enough.
  • We can reactivate that proposal if we have higher priority use case.
• #getting-started Sharing images is disabled on this server?
  • Yes, to help prevent spam and abuse.
• #language-questions Will Carbon have a standard library? How will we avoid problems like std::initializer_list being awkwardly split across language and library?
  • Yes, we’ll have a standard library, and we’ll also expose C++ std via interop.
  • One of our goals is evolution: rather than avoiding making mistakes, we’re trying to preserve our ability to fix our mistakes.
• #typesystem Creating leads issue to capture questions about array initialization from the #5545 review.
  • Should it focus solely on the library design question, or also encompass language design?
  • Probably both.
  • Filed as #6160.
• #typesystem If sum type alternatives are types, we could use is instanceof operator for conditional pattern matching.
  • Reads better than if let, particularly because the scrutinee goes on the left
  • It may be surprising to use is when the right-hand side isn’t a type.
• #style What should the mascot and logo be?
  • We’re intentionally postponing those questions for now.
• #getting-started #build-help Link errors with libunwind when building the toolchain on non-Ubuntu Linux.
  • Possibly the same problem as previous discussion?
  • Solved by compiling without libc++ or libunwind.
• #naming What would you call a type that isn’t a facet?
• #infra Weird “lost inputs” error forcing retries in the merge queue.
• #typesystem Is there a design for constraining types by their parent type?
  • Yes, see here.
• #language-questions Why treat type names as keywords?
  • Implicitly importing Core prevents you from using raw identifiers as a workaround. See here.
• #getting-started “Carbon and C++” example from the README doesn’t compile, because import Math doesn’t exist, and Main is the wrong name for the entry point.

RSS Feed for "Last Week in Carbon" here

[arpit-gahlot]

Love forms!