2025-07-28 — Last Week in Carbon

[josh11b]

Updates on leads issues

• Decisions
  • (none)
• New issues
  • (none)
• Active discussions
  • (none)

Updates on proposals

• Decisions
  • (none)
• New RFC proposals
  • (none)
• Active discussions
  • #5434 ref parameters, arguments, returns and val returns
    • Does bound include transitive reachability?
  • #5545 Expression form basics
    • Continuing to discuss presentation issues.
    • Need to make sure new presentation doesn't break struct initialization order (see also #typesystem 07-24).

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: Choosing next programming language community leader we want to talk to to learn from their community journey
• Activity in the past week:
  • Updated our AutoMod rules so we can catch more spam automatically
  • In the last 7 days in our repo: 7 authors pushed 20 commits to all branches, 19 of which to trunk, we changed 86 files with 3,130 additions and 1,246 deletions, we merged 20 PRs, opened 8 PRs, and we opened a new issue

Activity on toolchain

• #toolchain How to add new parse node kinds
• #toolchain Running clang++ through the carbon command line
• #toolchain Deleting temp directories
• #toolchain (1 2) Importing with virtual
• #toolchain (1 2) #5834 How to handle errors, such as from file operations
• #toolchain Disabling implicit impls for tests
• #toolchain Dumping in lldb
• PRs:
  • SemIR namer in #5806 #5808 #5839
  • C++ interop in #5836 #5842 #5849
  • virtual methods in #5841 #5843
  • errors in #5834 #5837
  • comments/docs in #5840 #5473
  • fuzzing in #5845
  • others in #5820 #5835 #5838 #5847 #5848 #5851

Activity on C++ interop

• #interop _bridged vs _mapped in test files
• #interop Try to put your name on a task in the toolchain tasks doc when you start it, to avoid duplicate work.

Other active discussions

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

• #pattern-matching 07-24 Discussion of suggested sum type design from last week
  • Proposed as/some pattern syntax diverges from expression syntax. Is that a problem?
  • "Bare" designators won't work inside stand-alone some, but arguably that's a pre-existing problem.
    • We can probably fix that with type deduction in other contexts.
  • Stand-alone use of some would require exponential compile time in general.
  • Meaning of extend in case ... extend.
  • How would some work as a general pattern-chaining operator?
• #typesystem Will we need a syntax to opt into type erasure and/or lifetime erasure?
  • Hopefully no syntax when it's just an optimization, but we'll need a syntax for when it's necessary for correctness.
  • ARC and ownership will presumably be library concerns.
    • Whether they have a keyword syntax is a separate question.
• #functions Link to C standard proposal N3657 Functions with Data - Closures in C.
  • Includes comprehensive overview of existing/proposed approaches.
• #getting-started Is there a way to shorten SemIR dumps?
  • --dump-semir-ranges can help. --no-prelude-import also helps indirectly, when applicable.
• #infra Should we set the "merge when ready" flag on our PRs?
  • PRs are considered ready when they're approved, even if there are comments outstanding.
  • Only an issue for people with write access.
• #typesystem 07-24 Does it make sense to talk about what an initializing expression evaluates to?
  • No, but in some cases a :? binding could still bind to it, by "time travelling" the storage location back to it once it's known.
  • We'd like to have a term for the result of expression evaluation.
• #typesystem Considering adding a new owning/non-owning dimension to references, closely connected to var.
• #typesystem Is this section of values.md effectively talking about -> let?
  • Basically yes.
• #typesystem 07-24 Clarifying our requirements on struct/class initialization order.
  • We want the initializer to always evaluate in lexical order, and then we want any additional conversions to happen in declaration order.
  • We don't want to materialize additional temporaries just to make the initialization order less surprising.
  • This can lead to dangling pointers in some corner cases, but hopefully our memory safety system will catch that.

RSS Feed for "Last Week in Carbon" here