2025-09-22 — Last Week in Carbon

[josh11b]

News

• Carbon Copy No.8: Classes Part II published!

Updates on leads issues

• Decisions
  • (none)
• New issues
  • #6068: Should impl lookup distinguish and/or fallback on const and/or MaybeUnformed?
    • Arose from discussion in #toolchain
• Active discussions
  • #6026: Why do we use .Self instead of the binding name?
    • Historical context from #780 and #818
    • 09-15 Reverse generics (like -> impl Trait in Rust) have no binding name and so would need .Self. Could revisit this decision if we decide not support that, but Rust & Swift both found the need

Updates on proposals

• Decisions
  • (none)
• New RFC proposals
  • (none)
• Active discussions
  • (none)

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)
  • DONE: first interview of a C# community leader about C#’s community journey
  • PENDING: second interview coming up
  • DONE: updated access to moderation shared folder documents for current team members only which had been made public in the past
  • WIP: Moderation skill self-assessment poll to plan for internal training or coaching sessions.
• Activity in the past week:
  • One new contributor?!
  • In the last 7 days in our repo: 10 authors pushed 37 commits to trunk, we changed 530 files with 29,528 additions and 23,946 deletions, we merged 37 PRs, opened 14 PRs, we closed 4 issues and opened 2 new ones

Activity on toolchain

• 09-16 #6065 Organization of files implementing C++ interop under check/, and possibly other reorganization to go with it.
• #toolchain 09-18 Getting the right facet type for I(.Self).
• #toolchain const types not being found in impl lookup
• #toolchain #6104 Representing different kinds of callables, maybe with std::variant?
• PRs:
  • C++ overloads in #5891 #6067 #6069 #6072 #6071 #6092 #6091
  • destroy in #6035 #6098
  • rewrite constraints and facet types in #6056 #6089 #6087
  • C++ imports in #6075 #6074 #6085 #6086 #6076
  • char keyword in #6078
  • C++ templates in #6080 #6084
  • str, including C++ interop in #6079 #6083
  • C++ references in #6082
  • C++ virtual function call interop in #6050
  • other C++ interop in #6047 #6065 #6096
  • docs in #6081 #6095
  • build infra in #6046 #6088
  • others in #6070 #6055 #6073 #6093 #6099 #6094
• New contributors:
  • @burakemir made their first contribution in #6081

Activity on C++ interop

• 09-16 Decided to defer importing C++ declarations indirectly and diagnose for now.
• #interop To support overload resolution with multiple access kinds, putting the access context information in the name reference instructions could be reasonable.
• #interop Matching Carbon (Cpp.std.string) and C++ (std::string) names in diagnostics: In Carbon diagnostics we should primarily talk about Carbon entities, and include extra information to give the spelling in C++ for things imported from C++, and vice versa.

Activity on memory safety

• 09-15 Tracking invalidation of containers vs. elements separately is helpful for fixing code that holds references to elements across invalidation
• 09-15 Groups from An alternative model for "lifetimes" in Mojo.md · GitHub are like Carbon's alias sets but are typed
• 09-15 How is the public API of a type affected by effects on private members?
• #safety Emerging consensus to focus on pointer/reference invalidation rather than borrow-checking, and model it as an effect in a type-and-effect system.
  • Requires tracking "alias sets" on pointers and references, which describe regions of memory they can access.
  • Also track what kinds of operations they can do (read, write, shape-destroying write).
  • Early draft doc in progress.
  • Can/should unsafe functions have safety annotations, which aren't definition checked but are used to check the caller?
  • What's the significance of calling it a "type and effect system"?
    • See Three meanings of effects
  • Major risks/concerns: annotation burden, and over-restrictiveness.
  • How does invalidation relate to lifetime? Do pointers need to be destroyed before they're invalidated, or can they just no longer be used?

Other active discussions

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

• #typesystem How would user-defined customization of sum forms work?
• #strategy In light of the discussion of sum forms, how should we proceed with sum types?
• #contributing-help Can we use GPLv3 code like readline in Carbon examples checked into our repo?
  • Yes, we just need to make sure they're marked test-only or something.
  • But for readline in particular, LLVM has its own, so using that may be simpler.
• #typesystem Would private adapt be a desirable feature?
  • We've been talking about unsafe adapt. Maybe that bypasses access control as well as safety?
    • Maybe not, because they're pretty separate concerns.
  • We don't have a mechanism for making implicit conversions private, but we know we'll need a way to do that in at least some cases.
    • We could say access control doesn't affect impl lookup, only whether you can use the impl once it's found. C++ has a similar rule, but it's been a problem in some cases.
    • For soundness reasons we probably don't want overloading to work differently in different contexts, but that means adding private impls can be a breaking change.
• #strategy Comparing Rust to Carbon, on LWN
  • Some notable factual errors.
• #style Would we be OK with using C99 array designators in our codebase?
  • Clang supports them in C++ as an extension, but MSVC does not.
  • The ambiguity with lambdas is messy, so unlikely to ever be in standard C++.
  • Would this tie Carbon to Clang in an unwanted way?
• #language-questions Is Carbon going to be a superset or subset of C++?
  • Neither, but it will have native C++ interoperability.
• #strategy How is the AI boom affecting Carbon?
• #generics-and-templates
  • Discussion of binding .Self references to the binding itself on the left of :!.
    • The places where we need to get a replaced FacetType for a binding with .Self in order to have a consistent view of types between T:! I(.Self) and I(T).
    • Discussion of type equality with facet types and .Self. Determined that two bindings in one function with .Self are different types, as they refer to different bindings. But the .Self in a parameter and argument can be the same, where the argument gets substituted in for the parameter binding.
    • The approach of building a replaced FacetType off of the facet type broke forward declarations since it created a different type in each decl.
    • Led to open discussion 2025-09-18 on the issue, where we found a new approach, which preserves .Self and moves from I(T) to something like I(.Self) instead of the other way around.
    • Discussion of --no-gen-implicit-type-impls depending on a FacetAccessType “shortcut” in convert when the conversion is to the exact type of the wrapped facet value. It breaks specifics with a symbolic facet value whose type is another symbolic facet value, as we then try to deduce the letter twice, once through FacetAccessType and once without.
    • Determined that the “shortcut” is load-bearing to preserve the facet value’s constant value (and thus type equality) when going through FacetAccessType. But also believe Deduce should not try to deduce the same parameter more than once inside a specific, just as it doesn’t for explicit function arguments.

RSS Feed for "Last Week in Carbon" here