2025-10-20 — Last Week in Carbon

[josh11b]

News

• Chandler just gave talk on Carbon (slides) at Rebase 2025.
  • #strategy Seemed very well-received. Lots of good in-depth follow-up discussion.

Updates on leads issues

• Decisions
  • #5969: Core type names and keywords for string types
    • str -> Core.Str
    • strbuf -> Core.StrBuf
    • buf -> Core.Buf
    • Core.CStr (no keyword)
• New issues
  • (none)
• Active discussions
  • #6160: How should array initializers be constrained?
    • Both options permit the target expression category to be a conversion input.
  • #5934: What kinds of type deduction do we want to support?
    • The decision here is linked to the design direction of sum types.
    • Seem to be two paths forward:
      • Model bare designators using type deduction, and model sum type alternatives as subtypes.
      • Model bare designators as "designator literals", and model sum type alternatives as factory functions
    • Lots of tradeoffs to consider.

Updates on proposals

• Decisions
  • (none)
• New RFC proposals
  • #6231: Disambiguate "value binding"
    • Discussed in #naming, #safety, and in PR
    • Proposes to use "value borrowing" instead of "value binding" for reference-to-value-conversion.
    • However, that might wind up conflicting with our safety terminology.
    • "Value capturing" or "value snapshotting" are also under consideration.
• Active discussions
  • #6177 C++ Interop: Mapping std::string_view to Core.Str
    • Looks close to ready; just needs updates to follow resolution of #5969.
  • #5913: Reworking unformed state
    • Having a ref parameter cause transition from MaybeUnformed to fully-formed feels unprincipled. Should we have genuine (but minimal) flow-sensitive typing instead?

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: Discussion of insights from interviews of C# community leaders about C#’s community journey among the moderation team
  • 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:
  • 2 new contributors!? 🎉
  • In the last 7 days in our repo: 8 authors pushed 32 commits to trunk, we changed 82 files with 5,023 additions and 2,264 deletions, we merged 32 PRs, opened 14 PRs, we closed 2 issues and opened 1 new one.

Activity on toolchain

• #generics-and-templates Should EvalImplLookupResult::has_concrete_value be true for final symbolic values?
  • Yes, but "concrete" might not be the right word. Let's try using "final" instead.
• 10-14 #toolchain Strategy for rolling out value store id tagging changes
• 10-14 #5543 Can we use AST unit instead, now that our approach for invoking Clang has changed?
• 10-14 Close to libc++ building and installing as a library. Questions about controlling whether it is used when invoking Clang through the Carbon toolchain
• 10-16 #toolchain #6236 Issue with no definition being generated for final blanket impls, adding a requires definition instruction to fix
• #toolchain People noticing gaps in the toolchain's implementation with finding headers, linking
• #toolchain #6222 Hashing in canonical value store includes hash of value not just key; so far those have been the same, but now there are more use cases.
• #toolchain Replacing addr with ref bindings.
  • Question about ephemeral reference expressions being replaced by lifetimes with safety work, but that can be dealt with separately.
• #toolchain How we plan to model forms in the toolchain
• #toolchain #6241 Found bug using the wrong interface id when importing
• #toolchain Switch signature of PrintChar to take a char instead of an i32.
• #toolchain #6247 Hex id clean up
• #toolchain Looking for good first issues
• PRs:
  • docs & comments in #6200 #6204 #6220 #6240 #6242
  • nullable C++ pointers, MaybeUnformed(T*), and Core.Optional(T*) in #6208 #6058 #6230
  • improve developer experience in #6209 #6218 #6228
  • unit tagging in #6207 #6212 #6213 #6214 #6215 #6216 #6226 #6244 #6248
  • generics in #6201 #6217
  • C++ Interop tests in #6199 #6221 #6232
  • other C++ Interop in #6211 #6219 #6237
  • others in #6205 #6222 #6227 #6229
• New contributors:
  • @boomanaiden154 made their first contribution in #6205
  • @gpokat made their first contribution in #6204

Activity on C++ interop

• #interop extern "C" seems to work. What are we missing?
  • Possibly nothing but tests to verify that it's working.
• #interop Looking for feedback on direction of #6250, which introduces Cpp.long_long.

Activity on memory safety

• #safety Safety Unit No. 10: private unsafe / public safe
• #safety Added question to safety unit 9: how do we want to represent ownership?
• #safety Possible thread-safety models?
  • Main three all seem to have Rust counterparts
    • Shared memory with locks and immutability.
    • Actor model, where single thread has exclusive access.
    • Copy model, where each thread has separate copy of shared data.
  • Everything seems simpler with structured concurrency. We might need no-leak types for that, as well as other reasons
  • But we'll probably have to support unstructured concurrency as well.
  • There's also behavior-oriented concurrency. See also this follow-up paper and this dissertation.
    • Addresses some problems with the actor model, particularly as implemented in Swift.
    • Direct successor to the Pony actor model.

Other active discussions

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

• #toolchain Can't run the "hello world" interop example on Mac.
• #toolchain Why does carbon link link against a different stdlib than the one it compiles?
  • It's not fully implemented yet.
  • Probably best to stick with Bazel builds for now.
• #build-help I see ref self:Self in examples, but it doesn't work.
  • Not implemented yet, but you can use the old addr self: Self* instead.
• #pattern-matching (Continued from last week) Why would you want to use Optional.Some(T) as a parameter type?
  • It's weird, but it comes up when you're implementing Optional(T).
• #typesystem Posted an update on issue What kinds of type deduction do we want to support? #5934 to try to move toward resolution on the design of sum types.
  • Only a high-level summary; intended to encourage follow-up discussion.
• #typesystem 10-14 Using a pointer as a value representation of MaybeUnformed(T) leads to pointers-to-pointers. How should we proceed?
  • MaybeUnformed(T) should try to use the same value rep as T, although that's complicated by the need to preserve padding that T doesn't care about.
• #general-design What's Carbon's plan for interface objects (like dyn Trait in Rust)?
  • We plan to support that, but it's future work because we don't immediately need it for interop.
• #syntax (continued from last week) How about using my_tuple.[Index] for computed tuple indexing?
  • Should we file an issue so we don't lose track of the problem with composite member access?
• #language-questions Why do we say to prefer Rust if you're writing new code?
  • We want Carbon to be a great language for writing new code, but it isn't mature enough yet.
  • Once it is, our guidance will probably be a more nuanced discussion of tradeoffs (e.g. does Carbon's extra complexity pay for itself in your use case?)
• #general-design Why does let b: B = a; not raise an error about missing Core.Copy, the way it does with var?
  • let makes an alias, not a copy.
• #strategy Upcoming Rust features for kernel development on LWN.
  • We may want to pay attention to types with unknown size and pinned initialization.
• #generics-and-templates The documented syntax for constraint "inheritance" doesn't match recent discussions
  • p5337 made changes here, but the docs haven't been updated. Fixing in #6240.
• #generics-and-templates Do we support fn in named constraints? It's not in the design, but we have parse tests for it.
  • We'll eventually support them in template constraints. See here.
• 10-16 Resolving ambiguity between designators used to specify associated constants in where expressions and alternatives in sum types
  • In where expressions, .Foo is rewritten to .Self.Foo, but that is potentially awkward for sum type alternatives.
  • Observation: conversions depend on the value, not just the type, independent of this concern, but comes up here due to .Self depending on the value
  • Proposed resolution:
    • Don't use .Self, use the name of the binding instead. Could remove complexity around .Self.
    • where expressions treat .designator =... and .(T.designator) =... as a special case, .designator in other positions has the sum type interpretation unless following the name of the binding.

RSS Feed for "Last Week in Carbon" here