Reworking unformed state #5913

chandlerc · 2025-08-05T23:51:46Z

Introduce a more formal model for how unformed state is managed for types. This
includes:

Specifying the interfaces used by types to opt into unformed state, and how
they work.
Providing a Core.MaybeUnformed(T) wrapper that models the API subset of
T available both when fully formed and unformed.
Initial concepts of unsafe adapt and unsafe as to model unsafe type
conversions between compatible types.
A flow-sensitive set of rules for how unformed types become fully formed.

proposals/p5913.md

danakj · 2025-08-06T21:00:07Z

proposals/p5913.md

+provided the API could legitimately initialize the type. After this cast, the
+object should be assumed well formed, as it would be normally.


I think this is saying that the following

var t: T; F(t unsafe as ref T);

Would consider t to be initialized after.

The proposal doesn't say this AFAICT. It says t is initialized if passed to a fn that takes ref MaybeUnformed(T) (but not MaybeUnformed(T)*).

So two potential gaps here, I think:

Does taking the address of the uninitialized var also make it considered as initialized? As most C++ out-params are going to be pointers.

Does forming a reference expression to T also make it considered as initialized, or just a reference expression to MaybeUnformed(T)?

FYI, It would be t unsafe as T not t unsafe as ref T. ref T is not a type, and this specific conversion will preserve the category so it is enough that t is a reference expression. On the other hand, it might be F(ref ...) if F takes a ref parameter, so this might end up being F(ref t unsafe as T).

I think the flow sensitive section does restrict this as it restricts the operation set.

Currently, I think even the above would be rejected. I think it has to be: F((ref t as Core.MaybeUnformed(T)) unsafe as T) ... which seems ... suboptimal.

We could build a wrapper to do the explicit escape:

unsafe fn Escape[T:! type](bound ref obj: Core.MaybeUnformed(T)) -> ref T { return obj unsafe as T; }

And then use it:

var t: T; F(unsafe Escape(ref t));

But it's not clear this is a great experience either.

Is it too ad-hoc to suggest unsafe ref instead of ref in this proposal to do this? Basically, unsafe ref would turn off the flow sensitive restrictions on unformed objects operation usage.

I suppose the down side is that we don't use ref for the object parameter, so this would only support non-methods. Personally, that works for me because methods I feel like are better situated to instead use Core.MaybeUnformed(T) themselves. Thoughts?

Perhaps we could allow the use of the name of a variable in an unformed state as the left operand of unsafe as in general? (In addition to allowing it to be implicitly converted to MaybeUnformed(T).)

Perhaps we could allow the use of the name of a variable in an unformed state as the left operand of unsafe as in general? (In addition to allowing it to be implicitly converted to MaybeUnformed(T).)

We could, it just feels like it'll be a bit surprising syntax wise:

var t: T; F(ref (t unsafe as T));

It seems strange to cast t to T right after declaring it with that type.

Relatedly, is this how we want ref-form-preserving as-style expressions (or other such expressions) to interact with ref markings on arguments? Do we need parentheses there? But those are all questions for ref, not unformed...

Hm. Yeah, I agree that unsafe as T is a bit surprising / strange.

In principle, a library function to do this seems like it could be reasonable. (Prior art for doing language-ish things like this in the library include the Rust drop function and C++ std::move.) I think it would currently look a bit worse than pictured above:

var t: Cpp.T; Cpp.T.Init(ref unsafe Core.Escape(ref t));

... which is a lot of extra syntax, not least because ref appears twice. But I think it might be reasonable to start with that; if we find there's sufficient pressure in practice, we could add an unsafe ref:

var t: Cpp.T; Cpp.T.Init(unsafe ref t);

proposals/p5913.md

josh11b · 2025-08-06T20:38:09Z

proposals/p5913.md

+choice, which result in its own set of tradeoffs:
+
+-   Types with neither of the above properties _cannot support unformed state_.
+-   Some types may elect to not support it as that may result in a better API
+    design for that specific type.


These two bullets don't seem to be describing the set of tradeoffs for not having unformed state, they seem to just be repeating "by necessity or choice."

Yeah, reworded.

proposals/p5913.md

josh11b · 2025-08-06T23:00:22Z

proposals/p5913.md

+Fundamentally, the goal of modeling unformed state is somewhat different from
+`MaybeUninit` -- it is about providing access to types' internal invalid or
+no-op states in order to provide improved ergonomics around initialization
+without a significant safety loss. It is very much focused on enabling _type
+design_ to opt into this, rather than intended for user code dealing with
+complex initialization. Carbon may well end up needing something like
+`MaybeUninit` to manage cases which cannot be modeled safely. Currently, the
+plan is to directly use raw storage for this, but if doing so surfaces an
+important abstraction layer on top like `MaybeUninit`, we should add it.
+
+The differences in functionality provided by `Core.MaybeUnformed(T)` and its
+expected usage (in assignment and destruction) follows from this different goal
+of allowing a type to create an efficient and ergonomic API with initialization
+flexibility.


This talks a lot about what Carbon's Core.MaybeUnformed(T) is trying to do, but not how that is different from what Rust's MaybeUninit does -- is it only "user code dealing with complex initialization"? I thought it included delaying initialization of things like I/O buffers until data was read -- which seems pretty similar.

Tried to do a better job of spelling out what I meant here, PTAL.

josh11b · 2025-08-06T23:01:21Z

proposals/p5913.md

+### Subsetting by fields
+
+We propose subsetting by fields rather than by a more complex approach such as a
+[bit-mask](#bit-mask-based-unformed-state) because this is expected to be easy
+to implement at low overhead, and meshes nicely with the struct literal syntax
+already present in Carbon. This seems like an effective starting position, but
+we should revisit it when introducing bitfields more fully to the language and
+determining how to reason about them.


Feels like maybe this section should be merged with the alternative considered (or just deleted since the alternative might be enough by itself).

Yeah, deleted this and the previous section. Not adding anything.

proposals/p5913.md

zygoloid · 2025-08-07T19:27:36Z

proposals/p5913.md

+The `UnformedHardenInit.StructT` type has similar restrictions as
+`UnformedInit.StructT` -- its fields must be a subset of the types fields, each
+a compatible-with type. Further, the `UnformedHardenInit.StructT` must also be a
+superset of the fields in `UnformedInit.StructT`. We refer to _hardening_ of an


Is it OK for the hardened build mode to use a different representation in the fields in UnformedInit.StructT than the representation that UnformedInit would use, or is the goal here only to allow additional fields to have values specified?

My goal was to let it have a different, but compatible representation. Although that may not have much utility. They're still fields of T, and each type has to be compatible with fields of T. And you can't access the fields (or the types used) from here. Reads always go through MaybeUnformed(T) and that in turn through the non-hardening struct.

I guess I'm worried about something like:

A pointer type says its unformed value is 0

We use that value for detecting whether it's unformed

It then says that its hardened value is some other bit pattern that's in some way better for hardening purposes

... and our "is it unformed" detection then fails to detect that a hardened unformed value is in fact unformed.

It'd be nice if we could make that kind of bug impossible, by ensuring that the hardened unformed state and the non-hardened unformed state are somehow consistent with each other.

This is what the match_first impls for IsUnformed provide when using the UnformedInvalid and UnformedHarden interfaces. It ensures when the harden interface is implemented, it is included in the InUnformed implementation.

The only way to write this bug is to use the lower level UnformedInit and UnformedHardenInit interfaces, manually implementing both, and then manually implementing IsUnformed incorrectly.

I don't really see a way to preclude that, but it at least seems like the well lit path doesn't end up there?

The challenge with making the unformed and hardened states required to be consistent is if the value used in the non-hardened case is lower cost but potentially less secure. In that case you want the value to differ between the two -- that's the whole point. The place where this comes up are things like indices where zero is a good, cheap unformed value, but happens to be "valid" and risky from a security perspective and so hardening prefers to set some other value like INT_MIN. Not expecting this to be common at all, but wanted to leave that flexibility in the design.

Hm. There's something that's not working well for me in this description: we talk about an object having "an unformed state" / "its unformed state" / "the unformed state" rather than having a set of unformed states, which to my reading implies that the thing that UnformedHarden gives you must either be consistent with what UnformedInit gives you (on the subset of fields that UnformedInit initializes) or is not an unformed state.

I think we don't have the terminology quite right, particularly about whether a type has a singular unformed state or a set of unformed states. If we want UnformedHardenInit to provide an unformed state, but not necessarily one that's consistent with the representation that UnformedInit provides, then the latter is not providing "the unformed state", just one possible unformed state, which means that the impl of IsUnformed in terms of the UnformedInvalid state isn't necessarily right, as there may be other unformed states. But if instead we want there to be a singular unformed state, then the state that an uninitialized variable is initialized to is not necessarily an unformed state (it won't be one in a hardened build), making the terminology there confusing, along with the name IsUnformed.

Perhaps we could use different words for the set of possible representations that an uninitialized variable can be in, versus the state that UnformedInit puts the object into? That might help to clarify that IsUnformed detects the former, not the latter.

This is what the match_first impls for IsUnformed provide when using the UnformedInvalid and UnformedHarden interfaces. It ensures when the harden interface is implemented, it is included in the InUnformed implementation.

I don't think that is a complete solution. For example, if a type provides an UnformedInvalid impl and an UnformedHardenInit impl, and the latter doesn't produce a state that's compatible with the one that UnformedInvalid computes, then you would use the second impl from the match_first, which does the wrong thing for a hardened value. (I think I'd be fine with rejecting that set of impls if there's a good way to do so.)

Do we expect the "hardened" state to be global, or could it vary between (say) packages in the same program? Do we actually need two sets of interfaces, and an or in the impl of IsUnformed, or could we instead have a single UnformedInvalid interface that sometimes produces a hardened value based on the build configuration?

proposals/p5913.md

zygoloid · 2025-08-07T19:49:29Z

proposals/p5913.md

+**Open question:** It isn't clear how implementing another conversion interface
+would work, but this is an issue already with adapters: how do you make an
+adapter conversion _implicit_? There is already an implementation of `As`, so
+implementing `ImplicitAs` would be an error -- it would be subsumed by the
+`extend impl as`. And even if you _could_, you couldn't actually write the
+Convert function as that would require using the synthesized one.


Would

impl as ImplicitAs(C) = C;

work? C is a compatible type that implements ImplicitAs(C).

proposals/p5913.md

Co-authored-by: josh11b <[email protected]> Co-authored-by: Dana Jansens <[email protected]> Co-authored-by: Richard Smith <[email protected]>

Co-authored-by: josh11b <[email protected]>

chandlerc

Thanks so much for all the review!!!

I think I've gotten to most and maybe even all of the comments. PTAL!

proposals/p5913.md

chandlerc · 2025-08-07T21:48:31Z

proposals/p5913.md

+choice, which result in its own set of tradeoffs:
+
+-   Types with neither of the above properties _cannot support unformed state_.
+-   Some types may elect to not support it as that may result in a better API
+    design for that specific type.


Yeah, reworded.

proposals/p5913.md

chandlerc · 2025-08-07T21:52:03Z

proposals/p5913.md

+The `UnformedHardenInit.StructT` type has similar restrictions as
+`UnformedInit.StructT` -- its fields must be a subset of the types fields, each
+a compatible-with type. Further, the `UnformedHardenInit.StructT` must also be a
+superset of the fields in `UnformedInit.StructT`. We refer to _hardening_ of an


My goal was to let it have a different, but compatible representation. Although that may not have much utility. They're still fields of T, and each type has to be compatible with fields of T. And you can't access the fields (or the types used) from here. Reads always go through MaybeUnformed(T) and that in turn through the non-hardening struct.

proposals/p5913.md

chandlerc · 2025-08-08T00:07:23Z

proposals/p5913.md

+provided the API could legitimately initialize the type. After this cast, the
+object should be assumed well formed, as it would be normally.


I think the flow sensitive section does restrict this as it restricts the operation set.

Currently, I think even the above would be rejected. I think it has to be: F((ref t as Core.MaybeUnformed(T)) unsafe as T) ... which seems ... suboptimal.

We could build a wrapper to do the explicit escape:

unsafe fn Escape[T:! type](bound ref obj: Core.MaybeUnformed(T)) -> ref T { return obj unsafe as T; }

And then use it:

var t: T; F(unsafe Escape(ref t));

But it's not clear this is a great experience either.

Is it too ad-hoc to suggest unsafe ref instead of ref in this proposal to do this? Basically, unsafe ref would turn off the flow sensitive restrictions on unformed objects operation usage.

I suppose the down side is that we don't use ref for the object parameter, so this would only support non-methods. Personally, that works for me because methods I feel like are better situated to instead use Core.MaybeUnformed(T) themselves. Thoughts?

chandlerc · 2025-08-08T00:09:26Z

proposals/p5913.md

+### Subsetting by fields
+
+We propose subsetting by fields rather than by a more complex approach such as a
+[bit-mask](#bit-mask-based-unformed-state) because this is expected to be easy
+to implement at low overhead, and meshes nicely with the struct literal syntax
+already present in Carbon. This seems like an effective starting position, but
+we should revisit it when introducing bitfields more fully to the language and
+determining how to reason about them.


Yeah, deleted this and the previous section. Not adding anything.

chandlerc · 2025-08-08T00:14:49Z

proposals/p5913.md

+Fundamentally, the goal of modeling unformed state is somewhat different from
+`MaybeUninit` -- it is about providing access to types' internal invalid or
+no-op states in order to provide improved ergonomics around initialization
+without a significant safety loss. It is very much focused on enabling _type
+design_ to opt into this, rather than intended for user code dealing with
+complex initialization. Carbon may well end up needing something like
+`MaybeUninit` to manage cases which cannot be modeled safely. Currently, the
+plan is to directly use raw storage for this, but if doing so surfaces an
+important abstraction layer on top like `MaybeUninit`, we should add it.
+
+The differences in functionality provided by `Core.MaybeUnformed(T)` and its
+expected usage (in assignment and destruction) follows from this different goal
+of allowing a type to create an efficient and ergonomic API with initialization
+flexibility.


Tried to do a better job of spelling out what I meant here, PTAL.

proposals/p5913.md

chandlerc · 2025-08-08T01:08:08Z

proposals/p5913.md

+**Open question:** It isn't clear how implementing another conversion interface
+would work, but this is an issue already with adapters: how do you make an
+adapter conversion _implicit_? There is already an implementation of `As`, so
+implementing `ImplicitAs` would be an error -- it would be subsumed by the
+`extend impl as`. And even if you _could_, you couldn't actually write the
+Convert function as that would require using the synthesized one.


I like the first one a bit more than the second, because we can't have a conversion to C while we're defining conversions to C...

Chatted a bit with @zygoloid about this live, and came up with the idea of explicitly extending the blanket impl when impl-ing the interface that produces the blanket impl. That seems like the case which we can make work (because we can use the explicit extension of the blanket impl to insist that we see it and everyone else sees it too), and ensure that our extension is coherent.

It does mean that we have yet another thing that makes negative constraints bad, but that seems OK.

I've added a description of this to the proposal, PTAL and let me know if this direction makes sense?

It raises some more open questions around final that I've added. Those at least seem more tactical questions we need to think through and less open-ended "how do we want this to work".

danakj

Few small things

proposals/p5913.md

Co-authored-by: Dana Jansens <[email protected]>

danakj · 2025-08-12T15:48:25Z

Not flipping an approval bit - but I am happy with this when @zygoloid and @josh11b are.

chandlerc

Actually posting my replies instead of just pushing the commit and leaving them pending... =D PTAL!

proposals/p5913.md

chandlerc · 2025-08-20T22:36:58Z

proposals/p5913.md

+The `UnformedHardenInit.StructT` type has similar restrictions as
+`UnformedInit.StructT` -- its fields must be a subset of the types fields, each
+a compatible-with type. Further, the `UnformedHardenInit.StructT` must also be a
+superset of the fields in `UnformedInit.StructT`. We refer to _hardening_ of an


This is what the match_first impls for IsUnformed provide when using the UnformedInvalid and UnformedHarden interfaces. It ensures when the harden interface is implemented, it is included in the InUnformed implementation.

The only way to write this bug is to use the lower level UnformedInit and UnformedHardenInit interfaces, manually implementing both, and then manually implementing IsUnformed incorrectly.

I don't really see a way to preclude that, but it at least seems like the well lit path doesn't end up there?

The challenge with making the unformed and hardened states required to be consistent is if the value used in the non-hardened case is lower cost but potentially less secure. In that case you want the value to differ between the two -- that's the whole point. The place where this comes up are things like indices where zero is a good, cheap unformed value, but happens to be "valid" and risky from a security perspective and so hardening prefers to set some other value like INT_MIN. Not expecting this to be common at all, but wanted to leave that flexibility in the design.

proposals/p5913.md

josh11b · 2025-08-26T03:31:45Z

proposals/p5913.md

+potentially accessing uninitialized memory. That hardening is expected to be
+handled by the compiler and language automatically.


Do you say that anywhere?

josh11b · 2025-08-26T04:44:41Z

proposals/p5913.md

+  fn Convert[self: Self]() -> Core.MaybeUnformed(T) {
+    // Initialize the fields of `T` that are part of `StructT`.
+  }


It seems expensive to check that the result causes IsUnformed to return true every time this happens, but the invariants of the system rely on that.

proposals/p5913.md

josh11b · 2025-08-26T04:48:35Z

proposals/p5913.md

+**Open question:** It isn't clear how implementing another conversion interface
+would work, but this is an issue already with adapters: how do you make an
+adapter conversion _implicit_? There is already an implementation of `As`, so
+implementing `ImplicitAs` would be an error -- it would be subsumed by the
+`extend impl as`. And even if you _could_, you couldn't actually write the
+Convert function as that would require using the synthesized one.


Fine with me. It seems to work with final, as you observed.

proposals/p5913.md

zygoloid · 2025-08-26T23:45:49Z

proposals/p5913.md

+The `UnformedHardenInit.StructT` type has similar restrictions as
+`UnformedInit.StructT` -- its fields must be a subset of the types fields, each
+a compatible-with type. Further, the `UnformedHardenInit.StructT` must also be a
+superset of the fields in `UnformedInit.StructT`. We refer to _hardening_ of an


Hm. There's something that's not working well for me in this description: we talk about an object having "an unformed state" / "its unformed state" / "the unformed state" rather than having a set of unformed states, which to my reading implies that the thing that UnformedHarden gives you must either be consistent with what UnformedInit gives you (on the subset of fields that UnformedInit initializes) or is not an unformed state.

I think we don't have the terminology quite right, particularly about whether a type has a singular unformed state or a set of unformed states. If we want UnformedHardenInit to provide an unformed state, but not necessarily one that's consistent with the representation that UnformedInit provides, then the latter is not providing "the unformed state", just one possible unformed state, which means that the impl of IsUnformed in terms of the UnformedInvalid state isn't necessarily right, as there may be other unformed states. But if instead we want there to be a singular unformed state, then the state that an uninitialized variable is initialized to is not necessarily an unformed state (it won't be one in a hardened build), making the terminology there confusing, along with the name IsUnformed.

Perhaps we could use different words for the set of possible representations that an uninitialized variable can be in, versus the state that UnformedInit puts the object into? That might help to clarify that IsUnformed detects the former, not the latter.

This is what the match_first impls for IsUnformed provide when using the UnformedInvalid and UnformedHarden interfaces. It ensures when the harden interface is implemented, it is included in the InUnformed implementation.

I don't think that is a complete solution. For example, if a type provides an UnformedInvalid impl and an UnformedHardenInit impl, and the latter doesn't produce a state that's compatible with the one that UnformedInvalid computes, then you would use the second impl from the match_first, which does the wrong thing for a hardened value. (I think I'd be fine with rejecting that set of impls if there's a good way to do so.)

Do we expect the "hardened" state to be global, or could it vary between (say) packages in the same program? Do we actually need two sets of interfaces, and an or in the impl of IsUnformed, or could we instead have a single UnformedInvalid interface that sometimes produces a hardened value based on the build configuration?

zygoloid · 2025-08-26T23:46:26Z

proposals/p5913.md

 valid state for the type. Types can customize the implementation of `IsUnformed`
 in the usual way for interfaces, but those need to uphold the contract of
 definitively testing for an object being in an unformed (and potentially
 hardened) state.


I think it'd help to rename UnformedHarden to UnformedHardenInvalid to emphasize that it must produce an invalid state, like UnformedInvalid does.

proposals/p5913.md

Following the direction of #5913, add support for parsing an `unsafe as` operator. For now, we allow one additional conversion using `unsafe as` beyond the conversions supported by `as`: we permit pointer conversions that remove qualifiers, such as `const T*` -> `T*`.

Co-authored-by: Richard Smith <[email protected]> Co-authored-by: josh11b <[email protected]>

CarbonInfraBot · 2025-09-04T00:21:38Z

proposals/p5913.md

+`extend impl` will end with a semicolon `;`, instead of a definition block in curly
+ braces `{`...`}`, but acts as a definition of the members of the extended
+ interface. This also allows
+the found _impl_ to be `final` because this precludes any changes to the aspects
+of the `impl` that were final. This allows adapters to extend which layer of
+these kinds of interface hierarchies they implement without breaking coherence:


[diff] _{reported by reviewdog 🐶}

Suggested change

`extend impl` will end with a semicolon `;`, instead of a definition block in curly

braces `{`...`}`, but acts as a definition of the members of the extended

interface. This also allows

the found _impl_ to be `final` because this precludes any changes to the aspects

of the `impl` that were final. This allows adapters to extend which layer of

these kinds of interface hierarchies they implement without breaking coherence:

`extend impl` will end with a semicolon `;`, instead of a definition block in

curly braces `{`...`}`, but acts as a definition of the members of the extended

interface. This also allows the found _impl_ to be `final` because this

precludes any changes to the aspects of the `impl` that were final. This allows

adapters to extend which layer of these kinds of interface hierarchies they

implement without breaking coherence:

CarbonInfraBot · 2025-09-04T00:21:38Z

proposals/p5913.md

+`IsUnformed` implementation (but do support unformed state) _must_ implement assignment and destruction with
+`Core.MaybeUnformed(T)`. When assignment or destruction are implemented with
+`Core.MaybeUnformed(T)`, they are called regardless of whether the object is in
+the unformed state. When assignment or destruction are implemented with `T`, the
+implementation will only call them if `IsUnformed` returns false and using the
+normal type. If the `IsUnformed` returns true in these cases, assignment will be
+replaced with initialization, and destruction will be skipped.


[diff] _{reported by reviewdog 🐶}

Suggested change

`IsUnformed` implementation (but do support unformed state) _must_ implement assignment and destruction with

`Core.MaybeUnformed(T)`. When assignment or destruction are implemented with

`Core.MaybeUnformed(T)`, they are called regardless of whether the object is in

the unformed state. When assignment or destruction are implemented with `T`, the

implementation will only call them if `IsUnformed` returns false and using the

normal type. If the `IsUnformed` returns true in these cases, assignment will be

replaced with initialization, and destruction will be skipped.

`IsUnformed` implementation (but do support unformed state) _must_ implement

assignment and destruction with `Core.MaybeUnformed(T)`. When assignment or

destruction are implemented with `Core.MaybeUnformed(T)`, they are called

regardless of whether the object is in the unformed state. When assignment or

destruction are implemented with `T`, the implementation will only call them if

`IsUnformed` returns false and using the normal type. If the `IsUnformed`

returns true in these cases, assignment will be replaced with initialization,

and destruction will be skipped.

nmsmith · 2025-10-19T03:27:21Z

proposals/p5913.md

+may be used subsequently: it may be used freely when its expression is
+immediately converted to the special type `Core.MaybeUnformed(T)`, but any other
+use is rejected until after it has been used as a reference parameter of type
+`Core.MaybeUnformed(T)` to a call other than the type's own destructor. That


This feels a bit too magical to me. Why should passing an argument as ref trigger a state transition from MaybeUnformed to formed? I can understand needing some way to trigger the state transition, but ref doesn't seem like a principled way to achieve this.

My intuition is that Carbon should have true flow-sensitive typing, albeit a very limited model that supports the use cases we require, and nothing more. It would come with a proper syntax, e.g. fn F(ref arg: Core.MaybeUnformed(T) becomes T).

Core.MaybeUnformed(T) can potentially be modelled as a sum type with two cases: .Formed(T) and .Unformed(T).

chandlerc added proposal A proposal proposal draft Proposal in draft, not ready for review labels Aug 5, 2025

Filling out template with PR 5913

d254a15

chandlerc force-pushed the unformed branch from cdbaddc to d254a15 Compare August 5, 2025 23:51

chandlerc added 2 commits August 6, 2025 00:19

port content

05f1419

expand remaining section and address feedback

a170e0b

chandlerc marked this pull request as ready for review August 6, 2025 01:19

github-actions bot requested a review from zygoloid August 6, 2025 01:19

github-actions bot added proposal rfc Proposal with request-for-comment sent out and removed proposal draft Proposal in draft, not ready for review labels Aug 6, 2025

danakj reviewed Aug 6, 2025

View reviewed changes

josh11b reviewed Aug 6, 2025

View reviewed changes

zygoloid mentioned this pull request Aug 7, 2025

How should modifiers for keyword operators be spelled? #5930

Closed

zygoloid reviewed Aug 7, 2025

View reviewed changes

chandlerc and others added 5 commits August 7, 2025 14:38

Apply suggestions from code review

c16a131

Co-authored-by: josh11b <[email protected]> Co-authored-by: Dana Jansens <[email protected]> Co-authored-by: Richard Smith <[email protected]>

Apply suggestions from code review

2f09917

Co-authored-by: josh11b <[email protected]>

review

b7b1b0a

fix

6118658

more review

bc76287

chandlerc commented Aug 8, 2025

View reviewed changes

chandlerc requested review from danakj, josh11b and zygoloid August 8, 2025 01:11

danakj reviewed Aug 8, 2025

View reviewed changes

proposals/p5913.md Outdated Show resolved Hide resolved

proposals/p5913.md Outdated Show resolved Hide resolved

proposals/p5913.md Outdated Show resolved Hide resolved

proposals/p5913.md Outdated Show resolved Hide resolved

proposals/p5913.md Outdated Show resolved Hide resolved

chandlerc and others added 2 commits August 8, 2025 08:44

Apply suggestions from code review

db3cf6e

Co-authored-by: Dana Jansens <[email protected]>

tweak

ac20c65

feedback

7b1ced5

chandlerc commented Aug 23, 2025

View reviewed changes

josh11b reviewed Aug 26, 2025

View reviewed changes

zygoloid reviewed Aug 27, 2025

View reviewed changes

zygoloid mentioned this pull request Aug 27, 2025

Add support for unsafe as operator to the toolchain. #5993

Merged

Apply suggestions from code review

af29332

Co-authored-by: Richard Smith <[email protected]> Co-authored-by: josh11b <[email protected]>

CarbonInfraBot reviewed Sep 4, 2025

View reviewed changes

format

91b35cf

nmsmith reviewed Oct 19, 2025

View reviewed changes

		provided the API could legitimately initialize the type. After this cast, the
		object should be assumed well formed, as it would be normally.

		potentially accessing uninitialized memory. That hardening is expected to be
		handled by the compiler and language automatically.

Reworking unformed state #5913

Are you sure you want to change the base?

Reworking unformed state #5913

Uh oh!

Conversation

chandlerc commented Aug 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

chandlerc left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chandlerc commented Aug 5, 2025 •

edited

Loading