2025-11-24 — Last Week in Carbon

[josh11b]

Updates on leads issues

• Decisions
  • (none)
• New issues
  • (none)
• Active discussions
  • #6160 How should array initializers be constrained?
    • #typesystem 11-18 Option (b) seems to require the target form to be an input to type conversion, but #5389 doesn't allow that. Should it?
      • Consensus seems to be no, it shouldn't, which means we have to choose option (a): arrays can be initialized from tuple values, not just tuple literals.
    • 11-20 For consistency, this means we should also allow implicit conversions from primitive to composite forms.
  • #6068 Should impl lookup distinguish and/or fallback on const and/or MaybeUnformed?
    • 11-20 Should follow #5389: conversions are marked on the interface, but impl can override.
      • We'll provide a blanket impl for const conversions that wraps the underlying conversion so it doesn't count as 2 conversions.
    • Fallback behavior should be opt-in, not automatic.

Updates on proposals

• Decisions
  • #6357 C++ Interop: Mapping pointer types
    • Approved and merged
• New RFC proposals
  • #6395 Type completeness in extend
    • extend declarations require the named facet type to be complete at the point of declaration.
• Active discussions
  • #5545 Expression form basics
    • #safety Any concerns with the proposed term "owning reference"?
      • Here it means "reference to a complete object" (rather than a sub-object)
      • It doesn't imply uniqueness or responsibility to destroy, so doesn't seem like a good fit.
      • Could we avoid needing this term by using a more Rust-like model where a local object's fields can be destructively moved?
    • #naming Better term for "reference to complete object"?
      • Treating ephemeral and durable references the same might help with terminology, but would require reversing the decision on #5250.
      • This term is also applied to the fields of an ephemeral reference to a complete object, but the intended model is that the act of destructuring makes those complete objects.
      • Going with "entire reference" for now, but there are other viable options.

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
• Activity in the past week:
  • A user was warned after making destructive comments, which were hidden
  • New contributor!? 🎉
  • In the last 7 days in our repo: 7 authors pushed 36 commits, 34 of which to trunk, we changed 372 files with 10,216 additions and 11,557 deletions, which means we merged 34 PRs, opened 12 PRs, we closed 2 issues and opened 2 new ones.

Activity on toolchain

• #toolchain #6399 Fix UAF by avoiding reallocations in RelationalValueStore
• #toolchain Entity names are not always canonicalized, and so are duplicated
• #toolchain Self specific with type generic
• #toolchain Refactoring the Function object to represent the return type directly
• #toolchain Dumping attached types
• PRs:
  • runtime building in #6380 #6381 #6390 #6417
  • DebugInfo in #6361
  • Remove addr in #6375
  • generic import in #6376 #6388 #6394 #6404 #6409 #6414
  • special ids in #6398 #6400
  • C++ macros in #6391 #6408
  • facet types in #6412 #6385
  • C++ virtual base classes in #6413
  • other C++ interop/import #6383 #6403
  • infra in #6407 #6406
  • others in #6377 #6384 #6387 #6389 #6393 #6392 #6399 #6401 #6371 #6405

Activity on memory safety

• #safety Could we allow destructively moving out of the fields of a local object, like Rust?
  • The plan is to support that by explicitly destructuring the object.
  • Rust-like model is flow-sensitive. Are we trying to avoid that?
  • #6118 is a draft principle to capture an approach where we don't avoid flow-sensitivity, but treat it as separate from type-checking.
• 11-20 What should we prioritize going forward?
  • Definition checking algorithm more important than checking calls
  • Still open questions around the call effect
  • Ergonomics
    • Need to figure out syntax and defaults
    • Can we imply effects from types in some way?
• #safety We now have a Drive folder to collect safety units and related docs.
• #safety Link to some interesting research languages
  • InvalML in particular seems very similar to our direction.
  • Doesn't support flow-sensitive invalidation, though.
• 11-21 Inventing alias sets for return values
• #safety 11-21 The Mezzo language is an excellent example of flow-sensitive checking.

Other active discussions

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

• #ints-and-floats Different ways to segment a unicode string.
• #infra #6387 should fix the flaky tests reported last week.
• #generics-and-templates Does Carbon support qualified lookups in constraints, like where .(A.X)= {}?
  • Yes, we'll probably need that, but we didn't realize until late.
  • Rules are unclear, and might be different for where applied to an impl.
• #generics-and-templates Can a class method make an unqualified call to a method from an extend impl?
• #infra FizzBot had stopped sending notifications. Fixed by restarting, but if it recurs we'll have to look deeper.
• #typesystem (continued from review discussion) Why does p6357 put VoidBase in Core.CppCompat if it's notionally the base class of all Carbon types?
  • It exists for compatibility with C++ void*, but it needs to support Carbon-defined types because they can cross the interop boundary.
  • We're mostly deferring the question of what Carbon-native type erasure looks like.
• #standard-library There's no standard library in 0.1 plan. Will developers be expected to use the C++ standard library? How will package manager work in relation to safety?
  • No clear connection between package manager and safety.
  • 0.1 is meant for evaluating if Carbon is working, not to support ordinary usage, so standard library is mostly deferred.
  • C++ std won't provide safety, so we'll need a native standard library eventually.
• #infra The dependency-check test was broken because it doesn't run in the merge queue. #6407 has the fix.
• #generics-and-templates Does Z need to be complete here?
  • Generally want to be permissive about ordering where possible. In this case we shouldn't need completeness because there's no member access.
• 11-20
  • We now support importing macros defined as constants!
  • Brainstorming what's still missing in checked generics implementation. Collected in #6411.
  • Naming convention for runtime directories.

RSS Feed for "Last Week in Carbon" here