2025-06-02 — Last Week in Carbon

[josh11b]

News

🎉 PR #5314 was submitted. It merges equivalent instantiations of generics while lowering.

• Our answer to fixing C++ template bloat automatically, as well as a key building block for having safety features like lifetimes fully participate in the type system.

Updates on leads issues

• Decisions
  • (none)
• New issues
  • (none)
• Active discussions
  • #5524 Semantic restrictions of immutable value (let) bindings
    • Proposed resolution leans heavily on erroneous behavior outside the strict safe dialect, and enforcement in the strict safe dialect
  • #5523 Orthogonality in the binding design questions prompted by #5434
    • Proposed resolution mostly aligned with the status quo and #5434's current form

Updates on proposals

• Decisions
  • (none)
• New RFC proposals
  • #5545 Expression form basics
    • 05-29 What needs to switch to being about forms, what can continue to use types
• Active discussions
  • #5448 Carbon/C++ Interop: Primitive Types proposal
    • 2 rounds of feedback
  • #5434 ref parameters, arguments, returns and let returns
    • updates to alternatives considered

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

• 10 trained moderation & conduct team members + community lead, in theory available from UTC-7 to UTC+5.5.
  • WIP: Talking community journey with Zig folks.
• Last week’s stats across our spaces:
  • In the last 7 days in our repo: 8 authors pushed 42 commits to trunk, we changed 725 files with 13,901 additions and 11,522 deletions, with 42 merged PRs, 10 open PRs, and 1 new issue.

Activity on toolchain

• #toolchain 05-27 How to plumb the flag for poisoning value stores? Doc with an idea to make it clearer in the code when value stores might be reallocated.
  • Conclusion: tools available in C++ to get this right are inadequate. Going to follow LLVM and change the value store representation to one that does not invalidate references to elements.
  • #toolchain Still want consecutive ids
  • #toolchain Small but acceptable perf regression
• 05-29 #toolchain #5548 #5584 Bug with importing a function member of a class while still importing the class
• #toolchain Discussion about reviewing golden test update PRs
• #toolchain #5580 Mysterious errors from ODR violation due to compiling different files with different flags
• PRs:
  • golden test updates in #5541 #5532 #5510 #5559 #5556 #5557 #5565 #5558 #5563 #5566 #5560 #5562 #5561 #5564 #5550 #5551 #5568 #5571 #5569 #5572 #5573 #5574 #5567 #5552 #5570 #5581 #5579 #5582 #5537
  • debug print in #5535
  • lowering in #5513 #5575 #5314
  • SemIR formatting in #5530 #5577
  • others in #5542 #5486 #5528

Activity on C++ interop

• #interop Should we generate Clang AST in the check phase?
• #interop Looking for feedback on using std::thread to bridge Clang and Carbon APIs in #5543.
• 05-27 Bridge (Simple ABI) functions
  • Passing struct by values makes sense as a first use case, though we could also consider passing everything (including primitives) by pointers.
  • Complete bridge function is the way to go. In the future (>1.0), to reduce AST size, we could consider building CallExpr that will turn into LLVM IR in Lower.
• 05-27 Where to define C++ imported long, long long, unsigned long etc.? Alternatives discussed, further discussions are necessary.
  • Cpp.usigned_long
  • Core.Cpp.unsigned_long
  • Cpp.unsigned(Cpp.long)
  • Cpp.std.unsigned_long
  • We also noted that if the types are not available by default, the user would have access to these types by doing import Cpp;

Other active discussions

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

• 05-28 #typesystem Considering alternatives to forms
  • Forms partition the binding information into types and other stuff that follows different rules. Also helpful for progressive disclosure.
• 05-28 #pointers-and-references How does the ref callsite marker affect overload resolution?
  • Consensus seems to be that it shouldn't.
• 05-28 Marking variance on form parameters to interfaces, as done with Scala, Kotlin, Typescript, C#. Rejected alternatives:
  • using the type of the parameters (doesn't work),
  • marking impls (doesn't give implicit conversions when calling a function parameter),
  • inferred (not aligned with Carbon's approach)
• 05-28 05-29 Interfaces with variant parameters behave differently
  • Can have overlap even with different argument values, need to add match_first to named constraints to disambiguate
  • Ability to override the variance on the impl to satisfy coherence
  • We can't have all of these, so relaxing the last one:
    • non-invariant parameters
    • definition checking
    • associated constants
    • consistent impl selection regardless of constraints
  • Introducing adapter types at function call boundaries
• 05-29 Carbon Copy newsletter on "classes with vtables" coming soon
• #pattern-matching Should we support destructuring types that are convertible to tuple/struct?
• #typesystem Proposed form terminology changes in #5545.
  • Do we need a term for the result of evaluating an expression?
• #getting-started Haven't heard any news/announcements for a while?
  • See last week in Carbon and the Carbon Copy newsletter.
• #proposals-prs-and-process Some design principles that we could use proposals for:
  • File concatenation
  • Progressive disclosure
  • The signature is the contract
• #pointers-and-references Are we going to want to express phase information in return forms?
• #general-design Looking for examples to illustrate progressive disclosure in language design.

RSS Feed for "Last Week in Carbon" here