Microsoft werkt aan een ingrijpende wijziging van de manier waarop C# omgaat met memory safety. Het bedrijf wil ontwikkelaars explicieter laten aangeven wanneer code potentieel onveilige geheugenoperaties uitvoert. Daarmee probeert Microsoft fouten rond geheugenbeheer beter zichtbaar te maken, juist nu AI-tools steeds vaker automatisch code genereren.
In een blogpost beschrijft Microsoft hoe het huidige gebruik van het sleutelwoord unsafe in C# volgens het bedrijf onvoldoende duidelijk maakt waar risico’s ontstaan. Momenteel kan een methode als unsafe worden gemarkeerd zonder dat alle potentieel risicovolle bewerkingen daadwerkelijk in een afgebakend blok staan. Daardoor is voor ontwikkelaars en analysetools niet altijd zichtbaar waar geheugenonveilige code begint en eindigt.
Microsoft wil dat veranderen door unsafe meer als expliciet contract te behandelen. Concreet betekent dit dat pointeroperaties en andere onveilige handelingen binnen een afzonderlijk unsafe-blok moeten plaatsvinden. Methoden die zulke risico’s doorgeven aan andere delen van de applicatie moeten daarnaast expliciet als unsafe worden gedeclareerd.
Veiligheidslabel werkt door in code
Onder het nieuwe model werkt het unsafe-label bovendien door naar code die zulke functies aanroept, legt The Register uit. Daardoor wordt beter zichtbaar welke delen van een applicatie afhankelijk zijn van potentieel risicovolle geheugenoperaties. Volgens de huidige voorstellen kunnen overrides straks bijvoorbeeld niet langer als unsafe worden aangemerkt wanneer de basismethode als veilig geldt.
Microsoft wil daarnaast het gebruik van unsafe verder verfijnen. Het wordt straks niet meer mogelijk om complete types als unsafe te markeren. Die scope verschuift naar afzonderlijke methodes, properties en velden.
Ook pointertypes zelf worden niet automatisch meer als onveilig beschouwd. Pas wanneer code daadwerkelijk unmanaged geheugen benadert via pointer-dereferencing ontstaat een unsafe-context. Daarmee probeert Microsoft nauwkeuriger onderscheid te maken tussen risicovolle en minder risicovolle operaties.
AI-code vergroot belang van controle
In de toelichting verwijst Microsoft nadrukkelijk naar de opkomst van AI-gegenereerde code. Volgens het bedrijf groeit de hoeveelheid automatisch geproduceerde software sneller dan menselijke ontwikkelaars alles handmatig kunnen controleren. Daarom wordt het belangrijker dat programmeertalen explicieter aangeven waar veiligheidsrisico’s kunnen ontstaan.
De wijziging past binnen een bredere trend waarbij programmeertalen strengere veiligheidsmodellen invoeren. Hoewel C# automatische geheugenbeheerfuncties behoudt via de .NET-runtime en garbage collection, schuift de taal met deze aanpassingen wel enigszins op richting talen als Rust.
Microsoft wil het nieuwe veiligheidsmodel aanvankelijk optioneel maken. Bestaande applicaties kunnen daardoor voorlopig volgens het huidige model blijven werken. Tegelijkertijd heeft het bedrijf aangegeven dat de .NET-runtimebibliotheken zelf wel direct op het nieuwe model zullen overstappen.
Daarnaast onderzoekt Microsoft of NuGet-packages een zichtbaar label kunnen krijgen wanneer zij het nieuwe veiligheidsmodel ondersteunen. Daarmee moet sneller zichtbaar worden welke libraries expliciet inzetten op memory safety.
Volgens Microsoft is het niet de bedoeling om onveilige code minder gevaarlijk te maken, maar vooral om zulke code zichtbaarder en beter controleerbaar te maken voor ontwikkelaars, securitytools en reviewers.
Gefaseerde introductie
Microsoft verwacht de nieuwe aanpak eerst beschikbaar te maken als previewfunctie in C# 15 en .NET 11. De uiteindelijke productieversie staat voorlopig gepland voor C# 16 en .NET 12, die volgens het reguliere releaseschema eind 2027 verschijnen. .NET 12 wordt bovendien een LTS-release.