2025-10-13 — Last Week in Carbon

[josh11b]

Updates on leads issues

• Decisions
  • (none)
• New issues
  • (none)
• Active discussions
  • #6160: How should array initializers be constrained?
    • Currently considering 2 different models
  • #5934: What kinds of type deduction do we want to support?
    • Multiple rounds of discussion including 10-09

Updates on proposals

• Decisions
  • (none)
• New RFC proposals
  • #6177: C++ Interop: Mapping std::string_view to Core.String
    • defines a direct, zero-cost mapping; relies on the two types having an identical memory representation
• 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)
  • DONE: Transparency report for last quarter
  • WIP: summary of interviews of C# community leaders about C#’s community journey for 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:
  • In the last 7 days in our repo: 9 authors pushed 29 commits to trunk, we changed 354 files with 14,165 additions and 12,674 deletions, we merged 29 PRs, opened 8 PRs, we closed 3 issues and opened 3 new ones.

Activity on toolchain

• #generics-and-templates Looking into crash in imports & interfaces.
• 10-06 10-07 #6168 #6175 Tagged InstIds make debugging difficult
  • #toolchain Thinking about printing inst5000009B as inst5..9B instead.
  • Lack of alignment and copy-paste support could be a problem.
• #toolchain Found a crash
• PRs:
  • C++ operators and overloads in #6156 #6171
  • facets in #6115 #6163 #6190
  • imports in #6176 #6180
  • .Self in #5957 #6181
  • C++ interop: reference types in #6178 #6187
  • Specific coalescing in #6191 #6196
  • C++ Interop locations in #6184 #6185
  • other C++ interop in #6179
  • others in #6165 #6192 #6183 #6194 #6193 #6197 #6198 #6203 #6195
  • docs in #6141 #6169 #6188

Activity on C++ interop

• 10-07 Decided to wait with further C++ operators details until the leads question is resolved.
• 10-07 Discussed sources for the `std::string_view` proposal.
• #interop Discussion on libc++ vs libstdc++ implementation of `std::string_view`.

Activity on memory safety

• 10-06 Summarizing for use in static analysis can be heavyweight
• 10-06 Static analysis can take N^2 time
• 10-06 Can use private/public split to limit code to vet when using unsafe
• 10-09 We should answer the question of the requirements on unsafe code later, not now
• 10-09 Can we still establish safety without having precise knowledge of alias sets?
• #safety Safety Unit No. 7: Globals
• #safety Could we guarantee that accessing a ref binding is always safe?
  • Seems hard to preserve a difference between pointers and references. So easy to go between them.
  • C++ pointers allow arithmetic, but Carbon pointers don’t.
  • If I pass a local into a ref parameter, can it invalidate or free the local?
    • The “invalidate” effect is incompatible with a var binding.
    • Earlier effort to list cases where an effect disallows certain inputs.
• #safety Should free() require that its alias set is a singleton?
  • Analysis probably won’t be that precise, and sometimes it will apply to more than one place.
  • But over-invalidating might be surprising, even if safe.
• #safety Went down rabbit hole from The Handle Trait to Dioxus Labs + "High-level Rust" to Leaving Rust gamedev after 3 years.
  • Dioxus asks for partial borrows, but what they really want is an in-place mutable update.
• #safety Safety Unit No. 8: Immutable and const
  • Might be able to simplify the type system by attaching immutability to alias sets.
  • (continued) We should support all 4 combinations of mutable/immutable and by-address/by-value. mut could be useful sugar.
  • Current approach lets us also talk about indirect mutation, but maybe there are other ways to get that?
• #safety For loops, could we have an alias set that takes an iteration index?
  • That seems like more precision than we can achieve efficiently.
  • We can’t require absence of pointer cycles as an inherent safety property; it has to come from a declaration somewhere.
  • But if the safety semantics we want can be declared, they need to be enforceable.
  • Separation logic seems relevant here.
• #safety Memory safety docs moved to a new subfolder.
• #safety Is it a goal that a single-threaded Carbon program has no undefined behavior if built with strict checking, and any code marked unsafe is sound?
  • Only if the code calling the unsafe code satisfies the preconditions.
  • We also want to avoid some erroneous behavior, not just UB. For example, preventing mutation of an immutable borrow.
    • Can’t that lead to UB, e.g. double-free?
    • Planning to make double-free and use-after-free EB – see here. That will be hard, though.
    • Maybe we need new category like “safety errors” for UB plus the EB we want to diagnose.
    • Not clear if we can actually define the behavior of double-free.
    • With sum types, unexpected mutation can lead to type confusion.
• #safety How will we decide overlap of alias path expressions that use ? ?
  • Different prefix or suffix establishes non-overlap.
  • Inheritance can hide things, but we won’t look at intervening types.
  • Looks like a subset of regular expressions? If so, there are algorithms for deciding intersection and containment, but they’re expensive.
  • These should only appear in effects.
• #safety Safety Unit No. 9: Linked -> owned

Other active discussions

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

• #contributing-help New contributor looking for pointers on how to start tasks from the toolchain task list.
• #language-questions Why is it better for the parser to produce a tree in post-order?
  • It gives subsequent stages the nodes in evaluation order.
  • Optimized for the compiler front-end, not for things like pretty printing.
• #generics-and-templates Use case where it’s necessary to say where .Self impls ... instead of & .... Is it possible to say extends instead of impls?
  • We’ve discussed it, but it looks like the & version is valid because of implied constraints.
• #typesystem Possible misunderstanding about “labeled expressions” model for bare designators: is the conversion from .Bar() to Foo.Bar() provided by the core language, rather than Foo?
  • If so, that works well for factories, but harder to see how it works for alternatives.
  • If so, can user code define the conversion in cases where the core language doesn’t?
  • Can we defer binding .Bar() to Foo all the way to runtime?
• 10-09 Discussion of bare designators.
  • Looks like two decisions are correlated: “designator literal” model works well if alternatives are factory functions, “type deduction” model works well if alternatives are types.
  • Both have drawbacks, we need to distill this down to a leads issue.
• #infra Is it intentional that Discord automod is blocking links to our own Discord?
  • We block Discord links as a spam control measure. Not sure how to exclude our server.
  • The server is the first part of the link, so a complicated regex might do it.
• #contributing-help Is there documentation about how the testdata files work?
  • testing/file_test/README.md has docs.
• #contributing-help How to write a test that has int types available?
  • Need to choose the right prelude from toolchain/testing/testdata/min_prelude/. You’ll need the full prelude for ints.
• #language-questions Continued discussion about why common type names are keywords:
  • There are no reserved words in Carbon, to help with things like interop. If word is a keyword you can use r#word instead.
  • We also plan to restrict shadowing heavily, so any implicitly-declared global names would behave like reserved words, with no raw-identifier workaround.
• #pattern-matching Seems like patterns like .Some(x: i32) might or might not be refutable, depending on context. Is that what we want?
  • Derived-class pattern matching base class scrutinee would have same phenomenon, but we’re not planning to support that.
  • Refutability comes from the sum->alternative type conversion, but seems like we want that to be contextual, and not tied to bare-designator patterns in particular.
  • Maybe this is OK because even if the pattern syntax doesn’t indicate refutability, the enclosing pattern-match does?
• #syntax Given this code:

class A {
  extend adapt (i32, i32);
  let template a:! i32 = 0;
}

• Does x.a evaluate to 0, or is it equivalent to x.(A.a), and evaluate to the first tuple element?
  • “First tuple element” would be very surprising, but breaking simple -> compound member access equivalence also seems bad.
  • Basic problem is that compound member access equivocates between a constant’s name and its value.
  • Not clear there’s an easy fix; we might need to disambiguate by changing either “computed tuple index” or “member access by qualified name” use cases to a different syntax.
• #typesystem Is there a way for user-defined types to do the trick where () is a value of type () as type?
  • Not yet. Seems like it requires a way to write a compile-time-only function.
• #typesystem Have we considered flow-sensitive typing? It could be useful for pointer invalidation.
  • We’ve tried to avoid it because of low context-sensitivity. But see #5913 for an example of getting similar functionality without putting it in the typesystem.
  • Flow-sensitivity for alias sets is different because it’s hard to express in the types of single identifiers.
• #toolchain Post discusses how to make cuckoo hashing fast

RSS Feed for "Last Week in Carbon" here