2025-12-08— Last Week in Carbon

[josh11b]

Updates on leads issues

• Decisions
  • (none)
• New issues
  • #6448 Syntax: clarification on "unused" keyword placement
    • Probably model unused as a pattern operator that applies to all the bindings inside it.
    • Probably consider a binding used if it is ever named, even if it's not evaluated.
  • #6456 Order of operations when initializing from a compound literal
    • Should evaluation be "depth-first", in order to reduce register pressure?
      • Probably yes. Preliminary experiments suggest this matters.
    • Arose from comment on review of Expression form basics #5545, and 12-02 discussion
    • #initialization How granular should this be?
      • Probably as granular as possible.
  • #6464 Is trivial destruction expressable as a requirement?
    • E.g. can code implement different behavior when a type is trivially destructible?
• Active discussions
  • #6161 How does partial interact with destruction?
    • Destructor should probably be changed to take a partial T.
    • We should probably change Destroy as well, but first we need to figure out how virtual destruction works.
    • 12-04 2 interfaces: Destroy uses dynamic dispatch, StaticDestroy uses static dispatch (but unsafe to call explicitly)
  • #2152 What should we call integer types with mod-2^N arithmetic?
    • Are the design questions here reopening settled decisions, or are they new information?

Updates on proposals

• Decisions
  • (none)
• New RFC proposals
  • (none)
• Active discussions
  • (none)

Activity on toolchain

• 12-02 #6457 install paths library
• #toolchain Building runtimes is working
• PRs:
  • interfaces and named constraints in #6435 #6443 #6444
  • facet types and values in #6437 #6445 #6438 #6458 #6461
  • copying C++ classes in #6434
  • impl lookup in #6452
  • C++ macros in #6454 #6441
  • infrastructure in #6455 #6447
  • other C++ interop in #6459 #6451
  • dependencies in #6462 #6471

Activity on C++ interop

• 12-02 Discussed aliases vs constants for macros that evaluate to constant variables
  • Agreed on evaluating to a constant, by default in a global namespace (Cpp.ENOENT), but also considering supporting child namespaces (Cpp.MyNamespace.ENOENT).

Activity on memory safety

• 12-01 Safety Unit No. 24: reducing effects
• 12-01 Modelling alias set components of types
• 12-01 Alias set syntax
• #safety Do we want a principle saying that safety annotations don't change the meaning of the code?
• 12-02 Considering whether the specifics about alias sets are included in types or forms & alias set effects in impls
• #safety Alternative to safety unit 24: instead of eliminating safety effects, try to subsume them into a more general typestate system
• #safety Idea of putting alias set restrictions as an effect in impls looks unsound in the presence of blanket impls.
  • Could we disallow impls for subsets of the space of alias sets? e.g. in Rust, lifetimes don't affect impl selection.
  • They're trying to add specialization on lifetime, especially for 'static, but we may not need that because of effects.
• 12-03 Same example using alias sets in types means choices about how to do specialization/overloading of impls by alias sets
• 12-03 Can be silent except when refining types
• 12-03 Reference alias sets by name, not position, to allow defaults and evolution
• 12-04 https://purplesyringa.moe/blog/a-look-at-rust-from-2012/ talks about when Rust had mutable aliasing in 0.5
• 12-04 Reference counting
• 12-04 New hybrid model for memory safety
• #safety What if different alias sets are required to be disjoint in all contexts?
  • We'll sometimes need to allow alias sets to overlap, so this would have to be an overridable default.
• #safety What happens if a safe function does impl lookup and finds an impl in a permissive library?
  • Requiring unsafe annotation in the caller will probably have unacceptable ergonomics, at least to begin with.
  • But do safe callers need to know that something unsafe happened in the impl?
  • Might mean even permissive code needs correct alias annotations (but we can probably have a good implicit default).
• #safety Safety Unit No. 25: hybrid flow-sensitive and fixed-by-types permissions

Other active discussions

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

• #getting-started Will Carbon support destructive moves? Will types be trivially movable by default?
  • Yes, Carbon will support destructive moves. See p0257 and #5913 for some of the groundwork.
• #typesystem Is moving an object different from writing to it, from a safety perspective?
• #proposals-prs-and-process #6395 was merged, but didn't receive explicit leads approval.
  • Non-leads, please remember not to approve proposals.
  • We could enforce this with CODEOWNERS, but p1367 has the rationale for not doing that.
• #getting-started Will Carbon be approachable for someone who doesn't know C++?
  • In principle, yes, but documentation will likely focus on C++ audience, especially early on.
• #error-handling Reviving proposal on errors, warnings, lints, and portability
• #language-questions Will Carbon support importing ANSI C or C99?
  • We're focusing on C++, but that should support the vast majority of C headers.
• #typesystem Pikchr could be useful for turning the "typish hierarchy" diagram into something we can check in.
• #infra Has anyone tried the Live Share extension for VSCode?
• #standard-library Should string indices be i32 or i64?
• #generics-and-templates Troubleshooting a crash
• #strategy No interop meetings until January 13
• #strategy Contributors, please be careful not to add personal events to the team calendar.
• 12-02 Into what builds should we inject include paths like libc++?
• #typesystem Clarifying the mention of "destructive move" in Expression form basics #5545
  • We expect destructive move to put the source in an unformed state.
  • Sometimes control flow is too complex for the compiler to tell if the move happened, so moved-from state has to be safe to destroy.
  • If that's not possible, wrap it in an optional to track lifetime dynamically.
• #infra More flaky failures in compile benchmark.
• #generics-and-templates Discussion of issue in the review of #6453
  • No, wait, it doesn't.
• 12-04 How can we support interface negation (e.g. do this if the type doesn't impl X)? How can types opt out of default-implemented interfaces like Destroy?
• #getting-started Reminder that posting jobs/resumes/etc is off-topic for this server.
• #initialization Should we "short-circuit" evaluation of expression patterns once we know the pattern won't match?
  • Probably yes.

RSS Feed for "Last Week in Carbon" here