2025-09-15 — Last Week in Carbon

[josh11b]

Updates on leads issues

• Decisions
  • (none)
• New issues
  • #6026: Why do we use .Self instead of the binding name?
• Active discussions
  • #5934: What kinds of type deduction do we want to support?

Updates on proposals

• Decisions
  • #6008: Replace impl fn with override fn
    • Implements decision in #5253
    • Approved!
• New RFC proposals
  • #5389: Generic across forms
    • First round of feedback
• Active discussions
  • #5990: Principle: The signature is the contract
    • #proposals-prs-and-process What should this principle be called?
  • #5545: Expression form basics

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)
  • Pending: first interview of a C# community leader about C#’s community journey
  • WIP: Moderation skill self-assessment poll to plan for internal training or coaching sessions.
• Activity in the past week:
  • One new contributor?!
  • In the last 7 days in our repo: 8 authors pushed 26 commits to trunk, we changed 619 files with 37,022 additions and 29,469 deletions, we merged 29 PRs, opened 9 PRs, we closed 3 issues and opened 9 new ones

Activity on toolchain

• #toolchain Is there a recursion issue in EvalLookupSingleImplWitness?
  • Yes, but probably not urgent.
• #toolchain Implementing "type is struct or tuple" constraint to help implement destruction, and maybe copying?
  • Unclear exactly what we'll need for copying. There are several different cases.
  • const and partial need special handling.
• #toolchain #style Should we disable the modernize-deprecated-headers clang-tidy check?
  • It's asking for changes like <time.h> -> <ctime>, which seems counterproductive because then we'd arguably have to say e.g. std::time_t.
  • Style guide is kind of unclear on this point
  • Done, in #6045
• #toolchain How should we render things like filesystem errors? Hard to make file tests portable. Just exempt them from test coverage and/or autoupdate?
  • Can also use {{.*}} to exclude non-portable parts of the test.
• #toolchain Rudimentary virtual call interop working in #6050
• #toolchain #6053 proposes a base type for bit-mask enums.
• #toolchain Considering adding a NameId::ImplicitPeriodSelf for use inside associated constant lookups. Avoids needing to provide .Self in facets where it doesn't make sense.
  • No, we should treat .X and .Self.X the same on the right-hand side of a rewrite.
• #generics-and-templates Seeing CHECK failure where the query_self_inst_id of a LookupImplWitness is an int literal, which seems very surprising.
• #toolchain How to fix a test that wants to demonstrate that a type is complete without requiring anything else of it?
  • There may not be a robust way to do that. For now we'll dereference a pointer to the type, with a separate test to warn if that stops requiring completeness.
• PRs:
  • C++ interop in #6005 #6020 #6030 #6024 #6049
  • examples in #5991 #6057
  • constraints in #6033
  • .Self in #6036
  • formatter in #6042
  • enum base type in #6043 #6053 #6054
  • filesystem library in #6000
  • imported impl lookup in #6040
  • Copy interface in #6034
  • return convention in #6052
  • infra in #6023 #6041 #6037
  • Others in #6019 #6021 #6004 #6038 #6039 #6044 #6045 #6048 #6051

Activity on C++ interop

• 09-09 Landing first overload resolution PR: Decided we can break some interop features to allow this to finish.
• 09-09 Calling class member operators requires identifying the function as a member method and converting the first arg to `self`.
• #interop Would like to have Carbon types for long long, unsigned long long, and long double. Should they be built in?
  • long long is sometimes an alias for int64_t -- should Carbon follow that? If so it makes overloading hard.
  • Maybe Core.Cpp.long_long is always distinct, and Cpp.long_long might or might not use it?
• #interop How should we support LLP64 in tests?
  • When it affects the test output, the test should have e.g. EXTRA-ARGS: --target=x86_64-linux-gnu.
  • A lot of tests will eventually be affected. Would be nice to have some organization scheme for duplicate LP64/LLP64 tests, or find a way to avoid duplication.
  • Do we have a way to test on LLP64 right now?
    • Yes, use --target=x86_64-pc-windows-msvc --clang-arg=-fno-PIE.

Activity on memory safety

• 09-09 Safety annotations will be implicit and flow sensitive within a function body, explicit on API boundaries
• 09-09 Consider what to do about effects together, not separately
• 09-09 Easier to make returned effects predicated on success or failure
• 09-09 Using types to model effects means having all the tools for types, but can lead toward the wrong default behavior
• 09-09 ref is an effect, or at least we have added most of the machinery we need for effects to handle ref. C++ users are fine with the separate references and pointer types. First is ergonomic, second is flexible/expressive/capable.
• 09-09 Discriminated union forms to return errors
• 09-09 Likely will want to support user-defined effects
• 09-09 Effects/forms for parameters, returns, and locals, not objects
• 09-10 Can put effects in return forms. Different kinds of effects treated differently:
  • returning a value of a category, multiple return
  • control effects: alternatives for errors, resumption for coroutines/async
  • safety effects
• 09-10 Syntax ideas for effects in the return form
• 09-11 Feeling positive about effect approach, feels like fits well with C++ mindset
• 09-11 If we go with an effects approach, should use effects system for more than memory safety
• 09-11 Mojo proposed safety model link; previous Carbon proposal
• 09-11 How would the effects approach look in our examples?

Other active discussions

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

• #typesystem What guarantees do we want to make about eliding copies/moves when destructuring tuples?
  • Elision would be nice, but not eliding is acceptable, and might be less surprising.
• #typesystem What categories do we want a ref self method to be callable on?
  • Current wording seems intended to allow calling on an initializing expression, but that seems to transitively allow calling on value expressions.
  • Limiting it to durable references (like ref bindings in any other position) seems simpler for now.
  • The memory safety system may give us a better solution, since the durable/ephemeral distinction is closely related to lifetimes.
    • But it's also trying to catch "lost" mutations of temporaries, which isn't a safety concern. We might still be able to leverage lifetimes, though.
  • Allowing returned var for parameters could address the use cases that want to call ref self methods on init expressions.
• #strategy Draft of the next Carbon Copy newsletter is available for review.
• #generics-and-templates Trying to figure out how to make T:! I(.Self) have the same type as
• U:! I(T).
• #infra We're switching CI from clang-tidy to clangd-tidy.
• #generics-and-templates 09-11 Running into a cycle replacing the T': .Self inside the type of T. Not sure how to avoid it.
  • Maybe have a sidecar id on FacetType that points to the same FacetType with .Self replaced?
  • That approach seems to work well in practice.
• #typesystem Should the syntax maybe be class Foo enum { ... } instead of enum class Foo?
  • That would help resolve #3652 question about how to forward-declare.
  • We have the same problem with base class Foo, though, so we should probably be consistent.
• #typesystem How to pass self to mutating methods of a type we want to live in registers?
  • Unclear. Possibly an exclusive reference (once those exist) or inout (if that exists), or use a copying value representation, or pass by ref and rely on the fact that refs are nocapture by default.
• #typesystem Is a class type with no vptr compatible with a struct with the same field names/types/order?
  • Not currently. Probably don't want them to be visibly compatible because it would break encapsulation.
• #syntax Why did we choose to have different syntax for struct literals and struct types?
  • Different things should look different. Using {.f = T} for types seems surprising, and {.f: v} for values would make : inconsistent.
  • Rust makes different tradeoffs because they appear in different contexts.
  • Feels awkward to use {.f = Form} in the "type" position, as proposed by #5389.
• #generics-and-templates Would it be feasible to have Core.Form where .type = SomeStruct that also constrains a particular field to have a particular form?
  • The expectation is that you write the struct form directly, but that gets unpleasant if you don't care about most of the fields.
  • Motivation is having a way to define e.g. StatusOr so that the discriminator can return in a register while the contents are returned in memory. Leads to the idea of its methods taking self as a struct form.
  • Instead you could model it as an ordinary sum type, and give the function a "sum form" like fn CanFail(...) either -> T or -> Status as recently discussed.
  • Not clear how that generalizes to other kinds of discontiguous representations.
• #typesystem Should "enum forms" and their alternatives be structural or nominal?
  • Enum types are currently nominal at both levels, but enum forms as recently sketched are structural at both levels.
  • Something like fn CanFail(...) -> StatusOr(T) either .Ok init(x) or .Error; gives us nominal enum forms while keeping the structure visible in the signature.
  • Alternatively, we could make sum types structural, e.g. StatusOr(T:! Type) = .Ok(T) | .Error(Status).

RSS Feed for "Last Week in Carbon" here