Microsoft รื้อ unsafe keyword ของ C# 16 ใหม่ทั้งหมด — เปลี่ยน 'syntax' เป็น 'caller contract' รับมือยุคที่ AI generate โค้ดไว

Microsoft .NET Blog เปิดบทความ “Improving C# Memory Safety” โดย Richard Lander (architect ของ .NET runtime) เมื่อวันที่ 21 พฤษภาคม 2026 — ประกาศการ redesign keyword unsafe ของ C# ครั้งใหญ่ที่สุดตั้งแต่ C# 1.0 ปี 2002

สิ่งที่เปลี่ยน — unsafe จะหยุดเป็น “syntax marker” ที่บอกแค่ว่า code block นี้ใช้ pointer และเปลี่ยนเป็น “caller contract” ที่บังคับให้ทุก unsafe operation:

1. อยู่ภายใน inner unsafe { } block ที่ scoped และ reviewable
2. มี /// <safety> documentation block ที่ describe caller obligation
3. มี compile-time enforcement ไม่ใช่ honor system

แบบที่ Lander เขียน: “safety contracts และ assumptions กลายเป็น visible และ reviewable แทนที่จะ implied by convention”

ทำไมต้องเปลี่ยนตอนนี้

Lander ระบุ 2 เหตุผลหลักในบทความ:

1. Memory safety เป็น priority ของ industry และ government

CISA, NIST, NSA, และรัฐบาลอเมริกาออกแนวทาง “memory-safe languages” หลายฉบับในช่วง 2 ปีที่ผ่านมา ตัวเลขจาก Google Security ระบุว่า memory safety bugs คือสาเหตุของ security bugs ส่วนใหญ่ ในระบบที่เขียนด้วย C/C++/legacy code

2. AI-assisted code generation ทำให้ human review ตามไม่ทัน

Lander เขียนตรง ๆ ว่า: “AI-assisted code generation adds a new dimension as software production scales faster than human review” — เมื่อ Copilot, Claude Code, Cursor, Antigravity, Codex สามารถ generate โค้ดได้เร็วกว่า human reviewer หลายเท่า, ระบบ safety เก่าที่อิง “convention” และ “คนรีวิวจะจับได้” ก็ไม่พอแล้ว

C# จึงต้องเปลี่ยนเป็นระบบที่ compiler enforce ได้ — ไม่ใช่หวังพึ่งคน

inspiration จาก Rust และ Swift

Lander ระบุชัดว่า C# 16 จะตาม “marking system ที่ Rust establish” — keyword unsafe ของ C# จะถูกใช้ใน 2 รูปแบบ (เหมือน Rust):

(a) Inner unsafe { } block — wrap operation ที่ unsafe เช่น dereferencing pointer, calling unsafe method, stackalloc, ฯลฯ

(b) Outer unsafe signature marker — บนตัว method/property/field declaration ที่ propagate obligation ไปยัง caller

ตัวอย่างที่ Lander ยกมาคือ Marshal.ReadByte — function ที่เดิม marked unsafe แต่จริง ๆ เป็น “pointer smuggling” เพราะใช้ IntPtr (ที่ดูเหมือน safe เพราะเป็น integer) ใน signature แต่ dereference ภายใน function code ใหม่จะ:

public static unsafe byte ReadByte(IntPtr ptr, int ofs)
{
    try
    {
        byte* addr = (byte*)ptr;
        unsafe       // ← inner unsafe block ที่ wrap dereference
        {
            return addr[ofs];
        }
    }
    catch (NullReferenceException)
    {
        // ...
    }
}

จุดที่ unsafe คือ addr[ofs] — ที่ทำ pointer dereference — ต้อง wrap ใน inner block, ไม่ใช่ทั้ง function

การเปลี่ยนแปลงเชิง breaking ที่นักพัฒนาต้องรู้

Lander ระบุการเปลี่ยนแปลงสำคัญใน new model:

• unsafe type modifier ถูกเลิก — เดิม public unsafe class Foo { } ทำได้, ใหม่จะ produce error
• unsafe ห้ามใช้กับ static constructors และ finalizers — เพราะไม่มี call site pattern ที่จะ wrap ใน unsafe { } block ได้
• new() generic constraint จะ match เฉพาะ safe parameterless constructor — type ที่มี unsafe parameterless ctor จะไม่ตรง
• เพิ่ม safe keyword ใหม่ — สำหรับ extern declarations และ LibraryImport partial method ที่ต้องเลือก marker explicitly
• Pointer types ใน signature ไม่ propagate unsafety แล้ว — เฉพาะ pointer dereferences เท่านั้นที่เป็น unsafe; byte* parameter ไม่ propagate ไปยัง caller โดยอัตโนมัติ
• เน้นใช้ typed pointers เช่น byte* แทน IntPtr — IntPtr กับ nint ไม่ต่างใน metadata; ถ้าเป็น pointer จริง ๆ ให้ใช้ typed pointer; ถ้าเป็น handle ให้ใช้ SafeHandle

Timeline

• Preview ใน .NET 11 — ที่กำลังจะออก
• GA ใน C# 16 — รายละเอียดเพิ่มเติมที่ GitHub issue dotnet/runtime#125800
• Library refactoring — System.Runtime.CompilerServices.Unsafe, System.Runtime.InteropServices.Marshal และ runtime libraries อื่น ๆ จะถูก uniform apply unsafe ตาม model ใหม่

นักพัฒนาที่ไม่ใช้ unsafe APIs เลย — ไม่ต้องเปลี่ยนอะไร เพราะ C# blocks unsafe code by default อยู่แล้ว ส่วนคนที่ใช้ — ต้อง refactor พอควรเมื่อเปิด new model

มุมมอง AI Curator

นี่เป็นการ acknowledge อย่างเป็นทางการของ Microsoft ว่า — AI ทำให้ programming language design ต้องเปลี่ยน ตัว Lander เขียนตรง ๆ ว่า AI-generated code ทำให้ “production scales faster than human review” และ language จำเป็นต้องมี compiler-enforced safety ไม่ใช่ honor system อีกต่อไป

ตอนผมอ่าน blog นี้ — สิ่งที่นึกถึงทันทีคือ Karpathy ที่เพิ่งย้ายไป Anthropic เพื่อทำงานด้าน pretraining กับคำพูดของ Dario Amodei ที่บอกว่า “revenue too hard to handle” ทั้งสองเรื่องชี้ไปยัง pattern เดียวกัน — AI development กำลังเปลี่ยน rate of change ของซอฟต์แวร์ จาก human-paced เป็น AI-paced

C# 16 เลือกตอบสนองด้วยการ อิง Rust-style safety ซึ่งฉลาด เพราะ Rust ทำเรื่องนี้สำเร็จแล้วใน production มาหลายปี ส่วน Java, Go, Swift ก็คงจะมี roadmap คล้ายกัน คำถามคือ C/C++ ที่ยังเป็น majority ของ legacy code base จะเปลี่ยนได้หรือไม่ — คำตอบของ industry ส่วนใหญ่คือ “rewrite ใน Rust” (เช่น Linux kernel, Android, Windows kernel) ซึ่งเป็น project มหึมา

สำหรับ นักพัฒนาไทย ที่ทำงานกับ .NET stack (ภาครัฐ, fintech, telecom, enterprise) ผลกระทบจะเป็น:

• โค้ดเก่าที่มี unsafe — ส่วนใหญ่ในเลเยอร์ interop กับ native (เช่น P/Invoke กับ Win32, native crypto, image processing) — จะต้อง refactor เมื่อ upgrade ไป .NET 11/C# 16
• AI coding assistants (Copilot, Claude Code, Cursor) ที่ใช้ generate .NET code — ต้องเข้าใจ new model นี้ ไม่งั้นจะ produce code ที่ compile ไม่ผ่าน ทีมที่ใช้ AI coding ควรอัปเดต .editorconfig, AGENTS.md (skill ของ Copilot CLI), หรือ Claude CLAUDE.md ให้ระบุชัดว่าใช้ new safety model
• Static analyzers (Roslyn analyzers, SonarQube, Coverity) จะต้องอัปเดตเพื่อรองรับ rule ใหม่ — ระยะ migration อาจมี false positive/negative มากในช่วงแรก

ภาพใหญ่กว่านั้น — memory safety เป็นเรื่อง mainstream แล้ว ไม่ใช่ niche concern ของ kernel developer หรือ embedded engineer อีกต่อไป CIO/CTO ของไทยควรถามทีม security ว่า — “ภายใน 18 เดือน เรามี plan migration ไป memory-safe language สำหรับ critical code path ไหนบ้าง?” — ถ้าคำตอบคือ “ไม่มี” นั่นคือ red flag

แหล่งข่าว

• Improving C# Memory Safety — .NET Blog
• Improving memory safety in C# — GitHub Issue dotnet/runtime#125800
• Memory-Safe Languages: Reducing Vulnerabilities in Modern Software Development — CISA
• The unsafe keyword in Rust — The Rust Programming Language Book