2025-11-10— Last Week in Carbon

[josh11b]

Updates on leads issues

• Decisions
  • #5903 Built-in character type questions
    • char models a UTF-8 code unit, but it may be invalid or part of an invalid sequence.
    • This supersedes the decision in #1964 to provide separate co-equal types for UTF-8, UTF-16, and UTF-32/UCS-4.
  • #5922 Built-in character operators
    • Character types will support arithmetic, comparison, and conversion to/from integers. See the issue for details.
  • #6275 C++ Interop: How to model distinct C++ integer types (long, long long) and their operations?
    • Add Core.Cpp.[U]Long32 and Core.Cpp.[U]LongLong64 to prelude, duplicating impls if necessary.
    • long maps to Cpp.long, and Cpp.long maps to either i64 or Core.Cpp.Long32, depending on the target.
    • For mixed arithmetic, choose return type that maximizes target independence of result types.
• New issues
  • #6342 Ambiguity in ref grammar
    • We use ref as an introducer for 3 different constructs, and it's not clear how to disambiguate.
• Active discussions
  • #6291 C++ Interop: How to map reference types (T&) vs. pointer types (T*)?
    • As of #5434 Carbon natively supports reference parameters and returns, but not fields or types.
    • Could use tag types like Core.Cpp.Ref(T) and Core.Cpp.RRef(T) for the remaining cases.
  • #6166 C++ Interop: How should C++ operators interact with Carbon operator interfaces?
    • Leaning toward hybrid "just in time" approach. Still discussing what the type structure of synthesized impls should be.

Updates on proposals

• Decisions
  • (none)
• New RFC proposals
  • #6331 Add import Cpp; for C++ built-in entities
    • Provides a way to import C++ built-in types, which have no header to import.
  • #6333 CLI and separate compilation
    • Aligning on high-level look and feel of carbon command.
    • 3 subcommands: compile, link, and build.
    • Mechanism for mapping library names in import to source files.
• 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)
  • WIP: Prepare resources to help close our skill gaps as identified by the team itself
• Activity in the past week:
  • Harmful language on Discord was reported, deleted and the accounts were banned
  • In the last 7 days in our repo: 7 authors pushed 21 commits to trunk, we changed 279 files with 7,435 additions and 3,001 deletions, which means we merged 21 PRs, opened 8 PRs, we closed 3 issues and opened 3 new ones.

Activity on toolchain

• #toolchain Foo::Check vs Check<Foo>?
• #toolchain Conversion to a type/facet when only types/facets would be accepted
• #toolchain enclosing specific for an Interface
• #toolchain building Clang and Carbon runtimes questions
  • currently being refactored
• #toolchain Controlling where compile output is written, and other questions about building
• #toolchain #6341 Repeated const handling
• #toolchain SemIR representation of ref, given that our model doesn't support replacing an instruction after generating more.
  • Filed issue #6342 to figure out the path forward
• 11-03 How are interfaces imported
• 11-03 What do we need to be included in the complete facet type?
• PRs:
  • void C++ Interop in #6302 #6315
  • named constraints in #6311 #6316 #6319
  • conversions in #6309 #6327
  • C++ Interop: non-nullable pointers in #6293
  • LLVM optimizer in #6225
  • const in #6323 #6341
  • lowering tests in #6328
  • variadic C++ interop in #6336
  • <<= and >>= C++ Interop in #6325
  • MaybeUnformed in #6334
  • other C++ interop #6317 #6306 #6320 #6332
  • others in #6313 #6322 #6339 #6340

Activity on C++ interop

• 11-04 Operators work unblocked following the discussion in #6166 leads question.
• 11-04 Nullable pointer issue is fixed by using the value representation of `T` as that of `MaybeUnformed(T)` where possible.
• #interop `import Cpp;` change should have a proposal.
• #interop Incomplete pointer types cause issue in reference parameter support work. Fixed in #6340.
• #interop Discussed how to access the C++ members of mapped types (like `std::string_view` -> `str`).

Activity on memory safety

• 11-03 Safety Unit No. 18: an object graph model
• 11-03 Should we switch to using "region" terminology instead of "alias set"?
• 11-03 Value representation of a box is the value representation of its contents
• #safety Whether and how to support passing an invalidated pointer.
  • Might be fairly common for pointers that are part of larger mutable graph structures.
  • Our static analysis probably won't be precise enough to prove that safe, but we'll need some way to limit the invalidation.
• #safety Safety Unit No. 17: Box -> owned
  • If we model Box as a unique pointer with its own alias set, we should probably do the same for Buf and most other container types.
• #safety Concerned that effects may fundamentally be not ergonomic enough.
  • "What's in the Box" and "Scoped Capabilities for Polymorphic Effects" papers seems to support this.
  • The fallback plan would probably be the capabilities model we started with.
  • The crux seems to be interaction between effects and generics.
    • This was the topic of Safety unit 14, and we don't have answers yet. Updated now with the options that look viable.
  • What happens if a higher-order function is passed a foreign function from a language without effects?
    • Probably give those functions broad effects by default.
    • Harder if the other language is a safe language like Rust -- more pressure to be either precise or conservatively correct.
  • Maybe "everything is implicitly effect-polymorphic" will be the best option for interfaces?
    • i.e. generic functions implicitly inherit effects from the impls they receive. Some research languages already do this.
• 11-04 How do we handle effects of implicit destruction of var parameters?
  • User-supplied effects of the function happen before the implied effects of returning from the function.
• #safety Safety Unit No. 19: effect catalog tries to give plausible minimum set of effects and alias set semantics
  • Safety Unit No. 20: examples from summit expresses the examples from the summit in terms of that catalog.
  • Identified some key open questions; biggest are probably interface effects and thread-safety.
• 11-05 #safety Considering having generic functions specify what interface methods they call, combined with [[unknown]] effect on those methods.
  • Could we rely on static dispatch most of the time, and check the call against the impl, ignoring the interface?
    • Sounds like giving up on definition checking, and making effects basically templated?
  • 11-06 There's interest in having interface methods constrain the effects that their impls can have.
    • We may need associated alias sets.
    • This is higher-order, so we'd need "effect constructors", similar to lambdas.
• #safety After trying for a couple of days, Nick! doesn't think it's possible to avoid having something like the [[free]] effect, so we have to bite the bullet of making effects work with generics.
  • But maybe we should give up on the free operation -- if Box is owning, nobody else should free.
• #safety Doc collecting resources on types, effects, regions, and capabilities.
  • Feel free to contribute.

Other active discussions

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

• #contributing-help What would it look like to migrate Core.String to array iterator?
• #syntax Trying to implement the agreed plan for disambiguating ref, but changing one of the spellings seems preferable.
  • Earlier discussion about ref might be relevant, but that's focused on ref in patterns, not expressions.
  • Now filed as leads issue #6342.
• #contributing-help Do I need to file an issue before sending a PR for a task in the TODOs document?
  • No, you can just send a PR directly.
• #language-questions How will Carbon interoperate with C++ exceptions?
  • Rough plan is documented here.
• #infra How is the bot's set of open leads issues chosen?
  • See documentation here.
  • Looks like some issues were getting dropped due to pagination. Fixed.
  • The list is now 4 messages long, but hopefully will get shorter as long-term labels are applied.
  • Use the "blocking" label if the issue is actively blocking work (or you expect it to be, by the time it's resolved).
  • Leads are finding it really helpful for prioritizing work.
• #infra How to find out what Carbon version Compiler Explorer is running?
  • Don't want to add a Core.Version string because people might depend on it.
  • As a workaround, you can embed C++ code that prints __clang_version__.
• #getting-started How to get started as Carbon developer on Mac?
  • Carbon isn't ready for use yet.
• #getting-started Will Carbon be for systems programming or general-purpose?
  • Suggest starting with the README and then diving into /docs.
• #generics-and-templates Clarification about how extend require works with identifiedness vs. completeness.
• #generics-and-templates Can a named constraint contain a class declaration?
  • No. If allowed it would be in the scope of the Self parameter, which probably isn't what you'd want.
  • We generally don't do a good job of saying what's not allowed.
• 11-06
  • Working on making it possible to call Carbon functions from the debugger.
  • Collecting examples of Carbon's parallelism/concurrency needs.
  • Should Bazel rules for Carbon be called e.g. carbon_binary, or something broader to reflect ability to compile C++ as well?

RSS Feed for "Last Week in Carbon" here