Some fixes to #5914 noticed after merging #6013

chandlerc · 2025-09-03T23:58:33Z

Several minor fixes to the content in the README.md were pointed out in review after merging that are fixed here.

I also accidentally undid the removal of the legacy strategy document. I think I got all of the critical content from this incorporated into the safety design section, but if there is more that I missed, please flag and I'm happy to improve that as part of this PR as well.

Several minor fixes to the content in the `README.md` were pointed out in review after merging that are fixed here. I also accidentally undid the removal of the legacy strategy document. I _think_ I got all of the critical content from this incorporated into the safety design section, but if there is more that I missed, please flag and I'm happy to improve that as part of this PR as well.

zygoloid

LGTM

It looks like the link style being used in safety/README.md isn't working on docs.carbon-lang.dev, so it might be worth looking into that too. Maybe there's just a flag we can set on the website to make it render those?

josh11b · 2025-09-04T17:17:48Z

docs/project/principles/safety_strategy.md

@@ -1,771 +0,0 @@
-# Safety strategy


I don't think this document should be deleted:

I think we should have safety principles, in addition to a safety strategy.

I think a lot of the content of the principles was not included in other documents as part of Updating Carbon's safety strategy #5914.

I think it would make more sense to rename this doc to "Safety principles" to clarify that it is more about tactics and approach than strategy. I think the content outside of the "principles" section can be deleted, along anything about build modes in the principles section.

At a high level, I'm happy to keep some updated form of the content you've flagged below that we shouldn't lose.

I'm not sure about keeping it under project/principles. They don't seem to really be principles in the same sense as our other principles have ended up. They seem more like our strategy or approach for the design of safety in the language. For other major areas of our design, the high level approach description is in the design itself and not in the project principles.

Separately, I think the content of the two principles flagged (at least) would benefit from being updated to reflect the pretty significant changes in approach that have happened. I can try to do that, but I'd also be happy for someone else to work on that -- would you be interested?

I talked to Josh and would be happy to do distill still relevant and adjusted safety principles as follow-up.

Should we file an issue, assign to me, and then move forward with deletion (I can access the content from here)?

See #6142 for the extracted principles.

josh11b · 2025-09-04T17:19:53Z

docs/project/principles/safety_strategy.md

-
-## Principles
-
-   Safety must be


This is something that I think is useful and not covered by #5914.

Does the updated strategy not cover this at least partially by mentioning incremental migration from C++ and the permissive vs strict distinction?

josh11b · 2025-09-04T17:20:00Z

docs/project/principles/safety_strategy.md

-        safety checks. They should also allow favor automation of testing and
-        fuzzing.
-
-   Safety in Carbon must work with


This is something that I think is useful and not covered by #5914.

Ditto, "permissive Carbon" seems to be more specific (without being overly concrete, so choices still need to be made.)

josh11b · 2025-09-04T17:20:12Z

docs/project/principles/safety_strategy.md

-        Although some safety features will be Carbon-specific, safety should not
-        stop at the language boundary.
-
-   The rules for determining whether code will pass compile-time safety


This is something that is covered (to some extent) by #5914.

Here I'd agree that this is recognizable as a principle.

I'd consider it somewhat obvious among people who work on static checking, but not everyone does so there is value in stating it explicitly.

josh11b · 2025-09-04T17:20:53Z

docs/project/principles/safety_strategy.md

-        different build modes. The purpose of the build modes is to determine
-        code generation.
-
-   Each build mode will prioritize performance and safety differently:


This is something that is covered (to some extent) by #5914.

I consider this here contradictory and would prefer there was only one place modes.

It seems to me that the spirit in which this older text was written placed more emphasis on runtime checks and various build modes, and that the direction has evolved towards pursuing rigorous memory safety.

I don't see a discussion of build modes as being an abstract principle, but rather very concrete choices. I'd wish principles (at least for safety) were short ad abstract, yet meaningfully constraining the design space.

I expect a lot of substantial design questions and decisions to juggle the multiple conflicting goals which are at play in a safety design, but I don't see a discussion of build modes as being a principle that can guide those.

josh11b · 2025-09-04T17:21:06Z

docs/project/principles/safety_strategy.md

-        binaries that prioritize safety that is resistant to attacks at the cost
-        of performance.
-
-   Safety checks should try to be identical across build modes.


This is something that is covered (to some extent) by #5914.

josh11b · 2025-09-04T17:22:03Z

docs/project/principles/safety_strategy.md

-    -   There will be differences, typically due to performance overhead and
-        detection rate trade-offs of safety check algorithms.
-
-   The number of build modes will be limited, and should be expected to remain


This is something that is covered (to some extent) by #5914.

josh11b · 2025-09-04T17:22:47Z

docs/project/principles/safety_strategy.md

-        Carbon developers, who can easily choose which is better for their
-        use-case.
-
-   Each distinct safety-related build mode (debug, performance, and hardened)


Is this still true? It would be good to have the answer to this documented, though it might be better in /docs/design/safety/README.md. I do think we expect "strict" files to be able to mixed with "permissive", which may also be worth saying.

josh11b · 2025-09-04T17:23:40Z

docs/project/principles/safety_strategy.md

-        by developers interested in combining libraries built under different
-        build modes.
-
-   Although runtime safety checks should prevent logic errors from turning into


This may be now covered by #5914.

josh11b · 2025-09-04T17:24:01Z

docs/project/principles/safety_strategy.md

-    For example, some safety checks would result in application termination;
-    this prevents execution of unexpected code and still needs to be fixed.
-
-   Developers need a strong testing methodology to engineer correct software.


I'm neutral on whether this should be retained.

github-actions bot added the documentation An issue or proposed change to our documentation label Sep 3, 2025

github-actions bot requested a review from zygoloid September 3, 2025 23:58

chandlerc mentioned this pull request Sep 3, 2025

Updating Carbon's safety strategy #5914

Merged

chandlerc requested a review from josh11b September 4, 2025 00:23

zygoloid approved these changes Sep 4, 2025

View reviewed changes

josh11b reviewed Sep 4, 2025

View reviewed changes

chandlerc mentioned this pull request Sep 24, 2025

docs: mark principles/safety_strategy as outdated, refer to update. #6123

Closed

josh11b approved these changes Sep 24, 2025

View reviewed changes

burakemir mentioned this pull request Sep 29, 2025

Adds extracted principles that are underlying Carbon safety #6142

Open

burakemir approved these changes Sep 29, 2025

View reviewed changes

Some fixes to #5914 noticed after merging #6013

Are you sure you want to change the base?

Some fixes to #5914 noticed after merging #6013

Conversation

chandlerc commented Sep 3, 2025

Uh oh!

zygoloid left a comment

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!

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!

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!