2025-10-27— Last Week in Carbon

[josh11b]

Updates on leads issues

• Decisions
  • #5969: Core type names and keywords for string types
    • str -> Core.Str
    • strbuf -> Core.StrBuf
    • buf -> Core.Buf
• New issues
  • #6275: C++ Interop: How to model distinct C++ integer types (long, long long) and their operations?
• Active discussions
  • #5934: What kinds of type deduction do we want to support?
    • Links to prior work in this area

Updates on proposals

• Decisions
  • #6231 Disambiguate "value binding"
    • "Value acquisition" is the new term for a primitive category conversion from reference to value.
    • Discussion in #naming (continued from last week)
  • #6177: C++ Interop: Mapping std::string_view to Core.Str
• New RFC proposals
  • #6254: Calling C++ Functions
• 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: Discussion of insights from interviews of C# community leaders about C#’s community journey among the moderation team
  • DONE: Shared moderation skill self-assessment summary, and creation of corresponding resources, internal training or coaching sessions for moderation and conduct team members.
  • PENDING: Providing according resources to help close our felt skill gaps
• Activity in the past week:
  • In the last 7 days in our repo: 8 authors pushed 27 commits to trunk, we changed 538 files with 10,673 additions and 6,017 deletions, we merged 27 PRs, opened 7 PRs, we didn’t close any issue and opened 2 new ones.

Activity on toolchain

• #toolchain User-facing diagnostics probably shouldn't talk about things like <pattern for ()>.
• #toolchain How will we support auto for bindings?
  • It would be nice if we could specify it entirely as desugaring to an implicit deduced parameter.
  • Not clear if we can, though, because we want to preserve the phase of the type.
• 10-21 How do we enforce parse-level restrictions on where ref can appear in expression context?
• #toolchain Would string indexing/iteration be a good first issue?
  • Yes, should just need a new builtin function and an impl.
  • Filed #6270.
• 10-23 #toolchain Should expression-ref be modeled in SemIR?
  • No, but textual SemIR should mark insts that are used where a durable ref is required (i.e. places where ref should be, besides ref Self arguments).
  • It seems odd for the textual SemIR to highlight information that's deducible from the actual SemIR, but not directly exposed by it.
  • If expression ref isn't in the SemIR, how can we diagnose a missing expression ref in a template?
  • Maybe it needs to be in SemIR, but not modeled as a separate inst.
• PRs:
  • "concrete" to "final" terminology for impls in #6246
  • unit tagging in #6241 #6251 #6243 #6258 #6257 #6256 #6259 #6263 #6260 #6262 #6267 #6265 #6273 #6274
  • C++ Interop: private in #6238
  • const conversion in #6253
  • named constraints in #6245
  • require...impls declarations in #6255
  • docs & comments in #6261 #6269 #6247
  • others in #6266 #6235 #6264

Activity on C++ interop

• 10-21 Discussed how to create distinct types for C++ builtins that require them (e.g. `Cpp.long_long`)?
  • We want to avoid duplicating the impls.
  • Have it mapped to Core.GenericInt(64, b)?
  • Make it an adapter for i64 and somehow inherit the impls?
  • We should also consider the return type of operations between these types and other builtins.
  • Related to that: How should we make C++ references distinct types in Carbon?
  • Decided to create leads questions.
• 10-21 Discussed tracking work.
  • Decided to explore using GitHub project feature, avoid requiring an issue for *every* PR, label automatically based on the code changes and learn from other similar projects.
• #interop Calling C++ Functions proposal.

Activity on memory safety

• 10-20 Would like there to be type differences between owning and not, so owning pointers treat copies differently
• #safety Safety Unit No. 11: type erasure
  • 10-23 Resolution: conceptually can include a base-to-derived conversion in an alias-set expression to recover an alias set that is hidden by derived-to-base type erasure.
• #safety Pony's reference capabilities are enlightening. See here for an explanation.
• 10-23 Generic copies should carry captures
• 10-23 Resolution to Carbon: Proposal tracking #11 is about ownership, still need tracking of aliasing/captures and disjoint in flow checking & effects. Those affect validity, not semantics.
• 10-23 Thread safety: different use cases prefer different models
• #safety Exploring an approach to safety that tries to rely more on features that are general-purpose rather than safety-specific.
• #safety Safety Unit No. 14: interface effects
  • Modeling temporal safety in interfaces seems like a strong constraint on possible designs.

Other active discussions

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

• #functions What type does a closure have?
  • Every closure has its own type, but it implements the Call interface, which acts like a traditional function type.
  • See p2875, especially here.
• #typesystem What is the category of if c then x else y if x and y have different categories?
  • We currently say it's always a value expression, but now that we have forms, maybe we could make CommonType form-aware?
• #syntax What is the precedence of the ref expression operator?
  • The intent of p5434 was probably to treat it as part of the function argument (and/or tuple literal element) syntax, rather than an expression operator.
  • Implementation is a little tricky because we don't know we're in a tuple literal until after we've seen ref.
• #generics-and-templates Does Self change when we encounter extend require impls J inside an interface?
  • Declarations inside an interface add names to lookup, which can be referenced by later declarations. See p5087.
• #typesystem Move, Destruct, Forget, and Rust
  • Discussion of different properties types can have regarding destruction and leaking.
  • Potentially interesting for safety, structured concurrency, and cleanup.
  • See also Substructural Type System proposal for Rust.
• #generics-and-templates Do we expect to be able to pass a tuple literal of chars to an array(char, N) parameter, where N is deduced?
  • It would certainly be nice, but it's not clear that generic deduction will support it.
  • Possibly we could make it work using something like C++ deduction guides?
  • That would also support other cases where there isn't a unique target type for the conversion, but there's some disagreement about whether we want that.
• #syntax It seems like X:! Y has different meanings depending on whether Y is an interface or a type.
  • It's actually the same meaning, because we model interfaces as types-of-types.
  • The risk of confusion was considered, but breaking the consistency of the current model adds complexity.
  • There's also a concern that people might incorrectly think of :! as having different meanings in () and [].
  • Our capitalization convention for runtime vs. constant should also help here.
• #syntax Could we make the capitalization convention mandatory, and drop the distinction between : and :!?
  • C++ interop constrains our ability to give semantic significance to naming choices.
  • Also, identifiers probably won't be restricted to the Unicode subset where "capitalization" is well-defined.
  • Go had bad experiences with making capitalization meaningful.
• #functions Blog post about adding explicit capture clauses to Rust.
• 10-23, #infra Extending FizzBot to ping leads about pending issues.
• #toolchain Should string indexing return a char or an Optional(char)?
  • Strong preference for char.
• #infra Experimenting with setting up a GitHub project to enable better progress tracking.
• #generics-and-templates Can we say require T impls Self in an interface?
  • Probably not directly, but you can do it by indirecting through another interface.
• #syntax Can't write something like this?

fn Foo[T:! type](input: T) where T impls SomeInterface {}

• Yeah, where is a binary operator with a type on the left, so it has to be fn Foo[T:! type where .Self impls SomeInterface].
• Syntax is different from other languages, but underlying concepts are the same.
• #syntax Can't write something like this?

fn Foo[T:! Core.ImplicitAs(U), U:! Core.ImplicitAs(T)](first: T, second: U) {}

• Yeah, you usually can't refer to a name before it's declared. You can write this instead:

fn Foo[T:! type, U:! Core.ImplicitAs(T) where T impls Core.ImplicitAs(.Self)](first: T, second: U) {}

• #generics-and-templates Could we model pointers with an interface rather than a type?
  • Motivation is to embed granular safety information in the pointer's type, without user having to write it.
  • We'll probably have such an interface, but a type will still be the primary way to pass pointers.
  • Seems burdensome to say that all functions that take pointers must be generic.
  • Shorthand syntax could help with some of that burden, but would still force a lot of code into API files.
• #pattern-matching is operator in Ante could be an alternative to if let.
• #typesystem "Bare designators" seem to resemble structural sum types in OCaml and Roc.

RSS Feed for "Last Week in Carbon" here