De Copy trait is ontstaan in het vroege ontwerp van Rust als een marker voor types die kunnen worden gedupliceerd via een eenvoudige bitgewijze kopie zonder zorgen over resourcebeheer. Drop werd geïntroduceerd om deterministische resourceopruiming af te handelen voor types die externe resources beheren zoals bestandsdescriptors of heapgeheugen. Het conflict tussen impliciete duplicatie en unieke eigendom werd duidelijk toen ontwerpers zich realiseerden dat bitgewijze kopieën niet-deelbare resourcehandles zouden delen. Daarom werd de compiler ontworpen om elk type dat beide traits gelijktijdig probeert te implementeren, te verwerpen.
Als een type dat Drop implementeert (bijvoorbeeld, het beheren van een bestandsdescriptor) ook Copy zou zijn, zou het toewijzen van de waarde aan een nieuwe variabele leiden tot twee bitgewijs identieke kopieën. Wanneer beide kopieën buiten scope gaan, wordt de aangepaste Drop-implementatie twee keer uitgevoerd op dezelfde onderliggende resource. Dit leidt tot een double-free kwetsbaarheid of use-after-free als de resource ongeldig wordt gemaakt door de eerste drop maar wordt benaderd door de tweede, wat de geheugveiligheid compromitteert.
De Rust compiler bevat een coherentiecheck in het trait-systeem die expliciet voorkomt dat een type zowel Copy als Drop implementeert. Deze beperking dwingt ontwikkelaars om Clone (uitdrukkelijke duplicatie) te gebruiken voor types die aangepaste vernietiging vereisen, zodat de implementatie correct referentietellingen kan verhogen of diepe kopieën kan uitvoeren. Door ervoor te zorgen dat elke logische entiteit een overeenkomende unieke drop heeft, behoudt het typesysteem nul-kosten abstracties zonder in te boeten op veiligheidsgaranties.
Overweeg een DatabaseHandle struct die een ruwe pointer naar een verbindingsobject in een externe C-bibliotheek omhuldt. De applicatie moet handles per waarde doorgeven aan meerdere closures voor logging, terwijl elke handle zijn unieke verbinding moet sluiten via een FFI-oproep wanneer deze wordt gedropt. Als de handle Copy was, zou impliciete duplicatie meerdere handles creëren die eigendom claimen van dezelfde onderliggende C-resource, wat onvermijdelijk zou leiden tot dubbele sluitingen of use-after-free wanneer de scope eindigt.
Een benadering was om Copy toe te staan en Drop te implementeren met interne referentietelling met behulp van Arc. Dit zou synchronisatie-overhead toevoegen voor elke handle, waardoor de binaire grootte en runtimekosten bij alle operaties toenemen. Het complicates ook de FFI-grens waar de ruwe pointer atomair uit de Arc moet worden gehaald, wat potentiële deadlocks introduceert als de drop-logica zelf terugroept naar Rust-code.
Een andere benadering was om Copy te gebruiken, maar te documenteren dat gebruikers een close-methode handmatig moeten aanroepen voordat de waarde wordt gedropt. Dit legt de verantwoordelijkheid voor geheugveiligheid volledig bij de programmeur, wat de kernprincipes van Rust overtreedt door fouten op compileertijd te voorkomen. Dit leidt onvermijdelijk tot resource-lekken wanneer ontwikkelaars vergeten om close aan te roepen, of tot dubbele sluitingen wanneer ze de handle per ongeluk kopiëren en proberen beide kopieën te sluiten.
De gekozen oplossing was om Copy te verwijderen en Clone handmatig te implementeren, samen met Drop. Clone voert een diepe kopie uit door een nieuwe databaseverbinding te openen, wat ervoor zorgt dat elke instantie zijn eigen unieke resource bezit en aliasing van de onderliggende C-pointer voorkomt. Drop sluit alleen zijn eigen verbinding, terwijl de compiler per ongeluk bitgewijze kopieën voorkomt, waardoor de veiligheid zonder runtime-overhead wordt behouden.
Het typesysteem voorkomt nu per ongeluk kopiëren op compileertijd, waarbij ontwikkelaars expliciet moeten aanroepen clone en de resource-acquisitie zichtbaar is in de broncode. Het programma voorkomt double-free fouten wanneer handles in threads of closures worden doorgegeven, en de deterministische vernietigingsgaranties blijven intact zonder de noodzaak voor atomische operaties of handmatig geheugenbeheer.
Waarom kan ik Copy niet afleiden voor een struct die een Vec bevat?
Een Vec is eigenaar van heap-gealloceerd geheugen en implementeert Drop om dat geheugen vrij te geven wanneer de vector buiten scope gaat. Als een struct die een Vec bevat Copy zou zijn, zou bitgewijze duplicatie twee structs creëren die naar dezelfde heap-buffer op de stack wijzen, maar beide zouden dezelfde pointer naar de heap bevatten. Wanneer de eerste struct wordt gedropt, wordt het geheugen vrijgegeven; wanneer de tweede wordt gedropt, probeert deze opnieuw hetzelfde geheugen vrij te geven, wat leidt tot ongedefinieerd gedrag. Rust voorkomt dit door te vereisen dat alle velden van een Copy type ook Copy zijn, wat recursief zorgt voor de afwezigheid van geneste Drop-implementaties.
Voorkomt mem::forget de problemen met Copy en Drop?
std::mem::forget consumeert een waarde zonder de destructor uit te voeren, maar heeft alleen effect op één specifieke eigendom waarde, niet op alle kopieën ervan. Als Copy en Drop waren toegestaan, zou het vergeten van één kopie andere bitgewijze kopieën niet verhinderen om hun Drop-implementaties uit te voeren wanneer ze buiten scope gaan. Die resterende drops zouden nog steeds proberen dezelfde onderliggende resource vrij te geven, wat leidt tot use-after-free of double-free ongeacht de vergeten instantie.
Kan ik ManuallyDrop gebruiken om Copy veilig te implementeren?
Het omwikkelen van een veld in ManuallyDrop voorkomt de automatische aanroeping van Drop, waardoor het technisch mogelijk wordt dat de buitenste struct Copy afleidt. Dit verschuift echter de verantwoordelijkheid om ManuallyDrop::drop aan te roepen naar de gebruiker voor elke afzonderlijke kopie die wordt gemaakt, wat effectief een handmatig geheugenbeheer scenario creëert. Als de gebruiker vergeet zelfs maar één kopie te droppen, lekt de resource permanent; Rust verbiedt dit patroon voor resource-bezitende types omdat het de veiligheids garantie van deterministische, automatische opruiming ondermijnt.