From a78cbea72b019410e21102fcad24077746501fc1 Mon Sep 17 00:00:00 2001 From: Andreas Rumpf Date: Tue, 9 Jan 2018 00:37:30 +0100 Subject: [PATCH] Updated Destructors (rest) --- Destructors.rest | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/Destructors.rest b/Destructors.rest index 799d88e..1528b66 100644 --- a/Destructors.rest +++ b/Destructors.rest @@ -146,6 +146,21 @@ Rule Pattern Transformed into ======== ==================== =========================================================== +Flaw 1 +====== + +A ``sink`` parameter cannot be passed to its destructor since the destructor takes a ``var T`` parameter and ``sink`` itself cannot be passed as ``var``. + +**Solution**: The destructor call is done on a temporary location that was bitcopied from the ``sink`` parameter or conceptually via ``unsafeAddr``. **Proof** that this is safe: After the destruction the ``sink`` parameter won't be used again. At the callsite either a copy was passed to the ``sink`` parameter which can't be used again either or an explicit ``move`` was performed which resets the memory and ensures that the it won't be used afterwards too. (Maybe this indicates that the destructor should also be a ``sink`` parameter and the ``reset`` step usually done in the destructor can be done by the compiler if required.) + +Flaw 2 +====== + +An analysis like "every code path provable leads to the parameters consumption" is hard to pull off, especially in a language like Nim with exceptions. + +**Solution**: The analysis can introduce a fallback path with hidden bool flags like ``if not flag: =destroy(sinkParam)``. Furthermore the compiler should probably get even smarter in its inference of ``raises: []``. + + Interactions with the GC ========================