2025-09-08 — Last Week in Carbon

[josh11b]

Updates on leads issues

• Decisions
  • (none)
• New issues
  • (none)
• Active discussions
  • #5922 Built-in character operators
  • #5903: Built-in character type questions
  • #5969: Core type names and keywords for string types
    • strbuf keyword for Core.StrBuf. str keyword for Core.Str
    • Also discussed in #naming.
  • #5934: What kinds of type deduction do we want to support?
    • About the interaction of designators implicitly converting to types and overloading

Updates on proposals

• Decisions
  • (none)
• New RFC proposals
  • #6008: Replace impl fn with override fn
    • 2nd proposal to implement the decision in #5253
• Active discussions
  • #5914 Updating Carbon's safety strategy
    • follow up in #6013
  • #5545: Expression form basics
    • some feedback

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)
  • Scheduled: first interview of a C# community leader about C#’s community journey
  • 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: 7 authors pushed 19 commits to trunk, we changed 220 files with 6,770 additions and 2,893 deletions, we merged 19 PRs, opened 6 PRs, we closed 1 issue and opened 2 new ones

Activity on toolchain

• 09-02 #generics-and-templates Implementing Self and .Self
  • #6009 Importing is not consistent, due to the need to deal with the difference between attached and unattached constants
  • Trying to figure out how to have the meaning of .Self change through the course of a where expression, as more rewrite constraints are added
• #toolchain One test takes longer to run than the others combined
  • One optimization in #6019, continue looking for more improvements
• #toolchain #generics-and-templates Unexpected SemIR changes due to inconsistent prefix exclusion
• #toolchain LLVM #153637 Debugging fixes for structured bindings
• #toolchain Namespacing globals
• #toolchain #6005 Can import from C++ static class members, even though not currently expressible in Carbon
• #toolchain Builtin constraints or builtin impl to help implement Copy and Destroy.
• PRs:
  • C++ interop recovery in #5992
  • MaybeUnformed(T) and unsafe as in #5989 #6014
  • associated constants parsing in #5973
  • C++ interop: binary operators in #5996 #6017
  • C++ RE2 library interop example in #5967
  • qualification conversions in #5999
  • test infra in #6011
  • lowering in #6012 #6010
  • others in #6003 #6022
• New contributors:
  • @elkalt made their first contribution in #5973

Activity on C++ interop

• #interop How will calling overloaded C++ operators work?
  • Unary operator* and operator-> should both map to a pointer-like interface.
  • operator& should not directly map to any Carbon syntax.
  • operator! is arguably unnecessary since not converts its operand to bool and always returns bool. Possibly that should invoke explicit conversions, like control flow conditions in C++? And maybe a C++ type that has operator! should be treated as having an explicit conversion to bool?
    • That could break when operator! is used for building a DSL rather than as a boolean operator.
    • Some folks would prefer to only invoke Core.As (explicit conversion) when the callsite looks like a conversion and names the type.
    • Then if (some_ptr) doesn't work, but that kind of construct has a history of causing bugs in some contexts. It's unclear how much that generalizes, though.
  • We should probably have some way of calling any C++ operator (e.g. operatorX?), and then make case-by-case decisions about when/how to expose it in a more natural way.
    • Would be nice if we could use something like raw identifier syntax so we can use the operator symbol in the name.
    • Does that mean operator will be a Carbon keyword?
      • Not necessarily. Depends on our lexing approach.

Activity on memory safety

• 09-04 Comparing proposed Mojo memory safety model from blog post to Carbon's proposed memory safety model
  • #safety Follow-up question about going from exclusive access to a range to exclusive access to disjoint subranges
• #safety Rust misses some precision for types with lots of fields, only a subset operated on. Would like some approach to field subsetting, like an adapter type.
  • Linked to blog post speculating about view types in Rust

Other active discussions

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

• 09-04 Use ref? in an impl to implement the same form interface twice?
• #syntax Is there a way to declare a global variable in a namespace?
  • var N.x: i32 = 0; should work, it's just not implemented yet.
  • That might not be a good first issue, because it's arguably a different syntax from other var declarations.
  • Note that the documented design has been superseded by the decision in #2590.
• #generics-and-templates Changing import to (almost) always work with canonical instructions, instead of importing non-canonical instructions in some cases (when importing an instruction with an attached constant from an eval block).
• #proposals-prs-and-process Do we have a way of tracking whether a given leads decision has been turned into a proposal, and whether it's been adopted?
  • Currently no. There was opposition to using issue labels, but don't recall why.
• #language-questions Can you compile existing C code with Carbon? Even if there are macros? Will migrating to Carbon make Rust interop easier?
  • The Carbon compiler is also a C++ compiler, but Carbon and C++ source files will normally be separate.
  • Carbon will probably interoperate with Rust more easily than C++ does, but it's too early to have many specifics.
  • Safe Rust APIs should be safe in Carbon, but safe Carbon APIs may not be safe in Rust.
  • Macros in C++ won't necessarily be visible to Carbon interop, but there are some common cases we think we can support.
• #safety Observation from RustConf: Rust where "view type" operations are hard to refactor because mutating methods have to borrow the whole object even if they only touch a subset of fields. Our safety story may solve this problem.
  • See here for more about the Rust view type problem.
• #pattern-matching New way of putting previous concern: the proposed double meaning of some may make some kinds of patterns inexpressible.
  • We can avoid that if as T some U only does one level of unwrapping, even though as T and some U both do one level of unwrapping on their own, but that's counterintuitive to some.
  • Perhaps as is always required, so as T, as some U, and as T some U always do one level of unwrapping?
• #pattern-matching Are var parameters destroyed in the caller or callee?
  • Caller-destruction would mean they couldn't be destructively moved in the callee.
  • Callee-destruction means pattern matching inside var has to happen in the callee, but we already do that.
  • So callee-destruction seems preferable, even when destructive move isn't possible for other reasons.
• #infra New contributor having difficulty running new_proposal script.
  • It requires GitHub label access.
• #infra Do we have a way to generate a pprof profile?
  • Looks like we mostly use perf instead.
• #syntax In #2590, why didn't we go with the option of var MyNS.(a: i32, b: i32) = ...?
  • That would still be a new top-level var syntax, so it sounds like leads wanted to start with something simple.
• #typesystem To what extent are case class C declarations real classes, rather than named structs?
  • If they're purely ordinary classes, they can't be destructured without explicit customization.
• #pointers-and-references Does inheritance subtyping apply to value expressions, and does it behave like derived-to-base conversion in C++?
  • It will work the same way for values and references, but might not be exactly the same as C++.
  • For example, if we can make derived and base pointers physically identical (unlike C++), we can support things like converting buf(Derived*) to slice(Base*).
• #language-questions Is Carbon still active? Is there an ETA for a stable release?
  • See the roadmap and our weekly updates.
• #infra FYI LLVM 21.1 is broken on MacOS.
• #safety In the under-development Mojo safety model, is there an equivalent of Rust's ability to support safe APIs with unsafe implementations?
  • Not yet, but lots of ideas being explored.
• #generics-and-templates Thoughts and confusion generated by working on the implementation of numbering .Self references in a facet type that refer to different things.
  • What does it mean to have a “less-specific” specific id, and to convert to it (from .Self to T or vice-versa when the .Self refers to that T).
  • How to do compound member access into a value of type facet-value? You can do non-compound member access into members of the facet-value’s facet type.
  • When to re-number .Self references for nested facet types?
• #typesystem Are member access expressions the only expression kinds that can be ephemeral reference expressions inherently (before considering conversions forced by the context)?
  • Looks like yes.
  • Is it concerning that array indexing, and (hypothetically) computed property access can't produce ephemeral references?
  • Maybe the safety design will solve this, since ephemerality is so close to lifetime?
  • Might need to adjust the rule that you can't assign to an ephemeral reference, because that's not exactly a lifetime issue.
• #llvm LLVM patch to export compiler-rt builtins is now merged upstream.
• #language-questions Will Carbon have a runtime? Will it be suitable for kernel development?
  • It won't have a VM or similar heavyweight runtime. It'll be suitable for the same kinds of things that C++ is.

RSS Feed for "Last Week in Carbon" here