Microsoft scherpt gebruik van unsafe-code in C# aan

In dit artikel:

Microsoft wil de manier waarop C# met memory safety omgaat ingrijpend aanscherpen: onveilige bewerkingen moeten explicieter gemarkeerd worden zodat ontwikkelaars en analysetools snel zien waar risico’s zitten. Nu kan een hele methode als unsafe worden aangeduid zonder dat duidelijk is welke delen daarvan daadwerkelijk met pointers of unmanaged geheugen werken; dat wil Microsoft veranderen door pointeroperaties en andere onveilige acties uitsluitend binnen aparte unsafe-blokken te laten plaatsvinden en functies die risico’s doorgeven expliciet als unsafe te laten declareren.

Het voorstel laat het unsafe‑kenmerk ook doorwerken naar de aanroepers: code die een unsafe-functie gebruikt, krijgt daar een zichtbare afhankelijkheid van. Daarnaast wordt het mogelijk niet meer om hele types als unsafe te labelen — de scope verschuift naar individuele methodes, properties en velden. Pointertypes op zich gelden pas als onveilig wanneer er daadwerkelijk gedereferenceerd wordt, waardoor een strakker onderscheid ontstaat tussen potentieel risicovolle en relatief veilige constructies. Ook overrides zullen niet langer automatisch unsafe mogen zijn als de basismethode als veilig wordt gezien.

Microsoft plaatst deze wijziging in de context van de snelle toename van AI-gegenereerde code, waardoor handmatige review lastiger wordt en expliciete taalconstructies belangrijker zijn. De verandering is bedoeld om onveilige code beter zichtbaar en controleerbaar te maken, niet om die veiliger te maken zonder aanpassingen. De nieuwe aanpak komt eerst optioneel als preview in C# 15 en .NET 11; de definitieve uitrol staat gepland voor C# 16 en .NET 12 (LTS) eind 2027. Microsoft onderzoekt ook labels voor NuGet-packages en stelt dat de .NET-runtimebibliotheken zelf direct op het nieuwe model zullen overstappen.