2025-09-29 — Last Week in Carbon

[josh11b]

Updates on leads issues

• Decisions
  • #6124: Should Destroy use a blanket impl for class types, or should it be instantiated per-class?
    • #toolchain #toolchain 09-23 09-24 09-25 There will be two interfaces: Destructor, with a private function used to customize, and Destroy, with a final/builtin function used to destroy complete objects, ending their lifetimes
• New issues
  • (none)
• Active discussions
  • #5934: What kinds of type deduction do we want to support?
    • Question about interaction with tuple and struct composition

Updates on proposals

• Decisions
  • (none)
• New RFC proposals
  • (none)
• Active discussions
  • #5545: Expression form basics
    • Feedback
  • #5389: Generic across forms
    • Incorporating 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)
  • DONE: second and third interviews of C# community leaders about C#’s community journey
  • PENDING: possible fourth interview coming up
  • BLOCKED: Moderation skill self-assessment poll to plan for internal training or coaching sessions. Data collection is still ongoing.
• Activity in the past week:
  • Off-topic comments were hidden on GitHub
  • In the last 7 days in our repo: 9 authors pushed 26 commits to trunk, we changed 279 files with 8,350 additions and 5,189 deletions, we merged 26 PRs, opened 10 PRs, and we closed 1 issue.

Activity on toolchain

• #generics-and-templates Discussion of what's included in EntityName canonicalization
• 09-25 How to validate the performance of InstId checking
• #toolchain C++ implicit conversions
• #toolchain Associate C++ operators with Cpp package, so we only look at them for C++ types
• #toolchain Lowering of facet values
• PRs:
  • impls and facets in #6120 #6107
  • C++ default arguments in #6108
  • C++ member operators in #6112
  • C++ deleted and templated constructors in #6129
  • runtimes in #toolchain #6002
  • C++ system header lookup in #6128
  • C++ multiple inheritance in #6130
  • Drop fn destroy in #6136
  • C++ mixed-access overload sets in #6137
  • other C++ interop in #6102 #6111 #6110 #6100 #6132 #6135 #6134
  • others in #6105 #6109 #6106 #6104 #6117 #6126
  • docs in #6121
  • deps in #6139
  • infra in #6131

Activity on C++ interop

• 09-23 Literals mapping for overload resolution
  • Integers and floats: Follow what C++ is doing.
  • Structs: Map to InitListExpr
  • Tuples: InitListExpr or std::tuple.
• 09-23 Next priorities: Macro list constants, lookup operators via impls, implicit conversions as impls.
• #interop How to do `impl` for C++ types.

Activity on memory safety

• #safety How long do temporaries live?
  • Not yet decided. Maybe end of statement?
  • One challenge for safety is that later destruction means more overlap.
• #safety Discussion doc on theory of alias sets.
  • Could use some examples.
  • More broadly, we need more examples of putting a safe API around code that the compiler can't prove safe.
• #safety Discussion doc on flow-sensitive alias sets.
  • It might be possible to remove alias sets from types and attach them to values using flow-sensitivity.
    • No lifetime parameters or place parameters of any kind.
    • Probably not the right direction, but there's a chance it could result in a simpler design
• 09-25 How do we handle use cases that use 'static in Rust?
  • Example: things without any lifetime parameters
  • Example: things in read-only memory like string literals

Other active discussions

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

• #style (continued from last week) Is it a problem for toolchain implementation to use Clang extensions?
  • Given our tight integration of Clang into the toolchain, portability of the toolchain source code to other compilers probably doesn't matter much.
• #strategy (continued from last week) Should we continue with the current approach to sum types, or re-think in light of "sum forms"?
  • Probably continue with current approach. Even if we change later, it will help to have this as a foundation.
  • Can a sum type alternative have ref arguments?
    • A user-defined alternative might be able to destructure to one or more refs, but wouldn't actually have a ref member.
• #error-handling Can we think of forms in terms of an "elaboration" step that compiles them away?
  • Probably, yes.
    • Value forms -> value representations
    • Reference forms -> pointers
    • Initializing forms -> pass destination address, return initial-value type.
  • What's an "initial-value type"?
    • The representation we use for types that don't have an in-place representation.
    • In generic code we have to model both passing the destination and returning the initial value, even though a given type only needs one or the other.
• #pattern-matching Do we want to support destructuring a class as if it were a struct, if its members are public?
  • In other words, do we want a class with public members to behave like a struct (e.g. support equality comparisons)?
  • Motivated by proposed case class in enum types.
    • Probably we can leave that out for now, because you can get the same effect with a case that extends a struct.
• #typesystem Do we need to forbid field declarations in enum class?
  • Probably not under the current direction.
  • UnrealScript even lets an enum have the equivalent of a vptr, which can change when the enum changes states.
    • If we might want that, we shouldn't use base to declare the discriminator type.
  • It's not clear how we'd initialize an enum class that has fields. We'd probably need something analogous to .base.
• #pattern-matching What should the initialization syntax for enum class stateless alternatives look like?
  • Currently var e: E = {} as E.X; but would be nice to have var e: auto = E.X or something like that.
  • No ideas for making auto work, but we can probably get something like var e: E = .X;.
• #control-flow Link to Imagining a Language Without Booleans.
• #infra Work in progress on a Discord bot to provide PR review reminders.
  • We have a Cloud account we can use to run the bot.
• #generics-and-templates We define "subtyping" as casting to a compatible type, but that implies subtyping is symmetric?
  • Yes, we need to fix the definition of "subtyping", but "compatible" still seems fine.
• #infra #6046 didn't fix ClangD integration with generated files. Trying again with #6131.
• #pattern-matching Does as ... some ... syntax do one or two levels of unwrapping?
  • One, but implicit conversion may effectively add a second.
• #typesystem How do we want initialization of nested enums to look?
  • Status quo is intolerable:

var o: opt(opt(i32)) = 42 as opt(i32).Some as opt(i32) as opt(opt(i32)).Some;

• We can probably get it down to:

var o: opt(opt(i32)) = 42 as .Some as .Some;

• Requires an aggressive approach to deducing the left-hand side of a bare designator (see issue #5934), and to extend transparency in enums, and some hinting in the enum.
• It would be nice if we could reverse the operand order, e.g.:

var o: opt(opt(i32)) = .Some of .Some of 42;

• Alternatively, if we model bare designators as free-standing parameterized labels that the enum defines a conversion from, we could have something like:

var o: opt(opt(i32) = .Some(.Some(42));

• That makes bare designators a pretty general-purpose tool for defining EDSLs.
• Not clear how to extend that to pattern matching given the current type-based approach to sum types.
  • Maybe we could define this syntax as a shorthand for the as one?
  • For modeling dynamic dispatch, could we nest the derived classes inside the base class?
• Does the type-based approach violate our previous decision to avoid type switching in general?
  • Probably not, because here we're always using some cooperative external indicator, not doing type comparisons directly.
• Chaining seems preferable to nesting in some ways.
• #pattern-matching How do we want the pattern syntax for nested enums to look?
  • Broadly similar concerns as with initializers, but the problems look solvable.
• #getting-started Is the toolchain usable to build a C++ project and try migration?
  • Not yet. Still working on reliably packaging the C++ standard library.
• #build-help Code that uses str doesn't link because of missing inputs.
  • Manually adding a linker input fixes it, but is there a simpler way?
  • Not yet. Eventually carbon build and carbon link should do it automatically.
• #strategy Ongoing public discussion of Comparing Rust to Carbon: HackerNews, lobste.rs, Reddit.
• #6140 Having trouble building on Arch Linux.
  • Eventually fixed by downloading LLVM and building/installing libunwind by hand.
• 09-22 Sum forms with effects

RSS Feed for "Last Week in Carbon" here