Updated NEP 2 Catching up with C and Rust: Ownership, destructors, unique pointers (markdown)

NEP-2-Catching-up-with-C---and-Rust:-Ownership,-destructors,-unique-pointers.md

@@ -1,3 +1,5 @@
+# WARNING: Work in progress, this section might contain content that doesn't make any sense yet.
+
 In the `c++` model, there are four steps that each object has to go through it its live cycle. 
 
 1. Allocation
@@ -67,9 +69,9 @@ Nim also needs some sort of move semantics, when it doesn't want to have everyth
 
 # My Suggestion to the problem
 
-My proposition is, to use swap, for things that are solved with move in other languages (C++). The idea to do is, comes from the fact, that Nim does not have the concept of a contructor, and therefore is not able to introduce a new kind of contructor. Neither does it have a state to describe a variable is moved from (ivalid to read). 
+My proposition is, to use swap, for things that are solved with move in other languages (C++). The idea to do is, comes from the fact, that Nim does not have the concept of a contructor, and therefore is not able to introduce a new kind of constructor. Neither does it have a state to describe a variable as _is moved from_ (ivalid to read). 
 
-Swap has the advantage, that it never introduces new entities, it just swaps two objects of the same type.
+Swap has the advantage, that it never introduces new entities, it just swaps two objects of the same type. Therefore the operation contains two move operations, but without destroying any other variable
 
 
 ## example
@@ -92,9 +94,40 @@ b.initialize
 swap(a.b,b)
 ```
 
+Now the move has been implemented with a simple swap. It is now possible to see, that `b` has after the swap only zero memory, because the member it was swapped from, was a member of an uninitialized member. If there is a destructor declared for the `MyMemberType`, it couldn't have any effect anymore, because zeroed out memory cannot possibly own anything.
 
-My proposition is, because Nim does not have uninitialized values. everything that can be expressed with move assignments, can also be expressed with `swap`, and swap already exists. Additionally to this, the compiler could make an optimization that prevents destructor calls on objects that are statically known to have only `zero` memory.
+## returning from a function
+
+Returning from a function could be implemented with a swap.
+
+```Nim
+proc foobar(): MyType =
+  result.a = 11
+  result.b = 12
+
+
+var fb = foobar()
+```
+
+background pseudocode:
+```
+var fb : MyType
+swap(fb, foobar.result)
+```
+if fb would have had any content from before the assignment, it would now be in `foobar.result` and therefore be cleared properly by cleaning the stack.
 
 ## swap does already exist, what does this proposition solve at all?
 
-Then the language would not need new features, it would just need to improve on already existing features.
+The language would not need new features, it would just need to improve on already existing features, and encourage the usage of them.
+
+### optimize away destructors on zero memory structs.
+
+Variables that are statically known to have only zero memory, cannot possibly have any ownership that needs to be released. Therefore the compiler could just optimize away any destructor call to variables that are known to be zero memory. Unlike c++, in nim the default initialization is always zero memory, so there might even be several circumstances, where this optimization actually takes place.
+
+# etc
+
+* Swap should be generic, and should not be overridden. Exceptions in a swap should be illegal.
+* What happens on exceptions, can there be objects that leak?
+* Assignment with types that have a destructor, but no copy/clone method should be illegal.
+* Assignment should be generic, and should not be overridden. 
+