Move caller-unsafe to accepted (#351)

* Move caller-unsafe to accepted

* Change unsafe link

* Add owner information and link to the C# language specification.

---------

Co-authored-by: Rich Lander <[email protected]>

Author: 333fred

INDEX.md

@@ -87,7 +87,9 @@ Use update-index to regenerate it:
 | 2023 | [net8.0-browser TFM for applications running in the browser](accepted/2023/net8.0-browser-tfm.md) | [Javier Calvarro](https://github.com/javiercn) |
 | 2024 | [.NET Standard Targeting Recommendations](accepted/2024/net-standard-recommendation.md) | [Immo Landwerth](https://github.com/terrajobst), [Viktor Hofer](https://github.com/ViktorHofer) |
 | 2025 | [.NET SDK Acquisition and Management Tool](accepted/2025/cli-acquisition-tool.md) | [Chet Husk](https://github.com/baronfel), [Daniel Plaisted](https://github.com/dsplaisted) |
+| 2025 | [Annotating members as `unsafe`](accepted/2025/memory-safety/caller-unsafe.md) | [Andy Gocke](https://github.com/agocke) |
 | 2025 | [dotnet tool exec and dnx](accepted/2025/direct-tool-execution.md) | : [Marc Paine](https://github.com/marcpopMSFT) |
+| 2025 | [Memory Safety in .NET](accepted/2025/memory-safety/memory-safety.md) | [Richard Lander](https://github.com/richlander) |
 | 2025 | [Provide SDK hint paths in global.json](accepted/2025/local-sdk-global-json.md) | [Jared Parsons](https://github.com/jaredpar) |
 | 2025 | [RID-Specific .NET Tool Packages](accepted/2025/rid-specific-tool-packages.md) | [Daniel Plaisted](https://github.com/dsplaisted) |
 
@@ -103,7 +105,6 @@ Use update-index to regenerate it:
 |Year|Title|Owners|
 |----|-----|------|
 |  | [Add ability to embed install location options in apphost](proposed/apphost-embed-install-location.md) |  |
-|  | [Annotating members as `unsafe`](proposed/caller-unsafe.md) |  |
 |  | [Rate limits](proposed/rate-limit.md) | [John Luo](https://github.com/juntaoluo), [Sourabh Shirhatti](https://github.com/shirhatti) |
 |  | [Readonly references in C# and IL verification.](proposed/verifiable-ref-readonly.md) |  |
 |  | [Ref returns in C# and IL verification.](proposed/verifiable-ref-returns.md) |  |

proposed/caller-unsafe.md …pted/2025/memory-safety/caller-unsafe.mdproposed/caller-unsafe.md renamed to accepted/2025/memory-safety/caller-unsafe.md proposed/caller-unsafe.md renamed to accepted/2025/memory-safety/caller-unsafe.md

@@ -1,12 +1,15 @@
-
 # Annotating members as `unsafe`
 
+**Owner** [Andy Gocke](https://github.com/agocke)
+
 ## Background
 
 C# has had the `unsafe` feature since 1.0. There are two different syntaxes for the feature: a block syntax that can be used inside methods and a modifier that can appear on members and types. The original semantics only concern pointers. An error is produced if a variable of pointer type appears outside an unsafe context. For the block syntax, this is anywhere inside the block; for members this is inside the member; for types this is anywhere inside the type. Pointer operations are not fully validated by the type system, so this feature is useful at identifying areas of code needing more validation. Unsafe has subsequently been augmented to also turn off lifetime checking for ref-like variables, but the fundamental semantics are unchanged -- the `unsafe` context serves only to avoid a compiler error that would otherwise occur.
 
 While existing `unsafe` is useful, it is limited by only applying to pointers and ref-like lifetimes. Many methods may be considered unsafe, but the unsafety may not be related to pointers or ref-like lifetimes. For example, almost all methods in the System.RuntimeServices.CompilerServices.Unsafe class have the same safety issues as pointers, but do not require an `unsafe` block. The same is true of the System.RuntimeServices.CompilerServices.Marshal class.
 
+See also the C# language proposal [here](https://github.com/dotnet/csharplang/blob/main/proposals/unsafe-evolution.md).
+
 ## Goals
 
 The overall goal is to ensure .NET code is "valid" with respect to certain properties, namely:

accepted/2025/memory-safety/memory-safety.md

@@ -1,5 +1,7 @@
 # Memory Safety in .NET
 
+**Owner** [Richard Lander](https://github.com/richlander)
+
 > **Memory safety** is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers. Source: [Wikipedia](https://en.wikipedia.org/wiki/Memory_safety)
 
 Security is our top priority. The .NET platform is a secure runtime environment, grounded in [memory and type safety](https://devblogs.microsoft.com/dotnet/why-dotnet/#safety), [defense-in-depth mitigations](https://github.com/dotnet/designs/blob/main/accepted/2021/runtime-security-mitigations.md), and other industry best practices. .NET enforces memory safety through automatic memory management, safety-aware code generation, and the separation of safe and [unsafe code](https://learn.microsoft.com/dotnet/csharp/language-reference/unsafe-code). We intend to improve safety by reducing the cases where unsafe code is required and providing developers with actionable feedback on the safety of their projects.
@@ -20,7 +22,7 @@ We expect that code safety requirements will become more strict over time and th
 Minimum requirements:
 
 - Document [Unsafe code best practices](https://learn.microsoft.com/dotnet/standard/unsafe-code/best-practices)
-- Introduce new [C# unsafe annotation and compiler feedback](https://github.com/dotnet/designs/blob/main/proposed/caller-unsafe.md).
+- Introduce new [C# unsafe annotation and compiler feedback](./caller-unsafe.md).
 - Annotate unsafe public APIs in dotnet/runtime libraries so that the compiler can provide feedback about their use.
 
 Opportunistically: