cadey
/
nim-wiki
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

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

This commit is contained in:
Arne Döring 2016-09-30 13:52:28 +02:00
parent 802e928737
commit 22a828b673
1 changed files with 10 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -50,7 +50,7 @@ proc `=`(dst: var MyType; src: MyType) =
dst.resources = src
```
I just heard, that self assignment on types that have deinitialization would not work anymore. This can be handled by implementing some logic that checks weather it is selft assignment, or by simply declaring self assignment illegal. One version that works with self assignment is the following (again in psoudocode), but it still needs to explain what move semantics are.
I just heard, that self assignment on types that have deinitialization would not work anymore. This can be handled by implementing some logic that checks weather it is self assignment, or by simply declaring self assignment illegal. One version that works with self assignment is the following (again in pseudocode), but it still needs to explain what move semantics are.
```Nim
proc `=`(dst: var MyType; src: MyType) =
@ -59,3 +59,12 @@ proc `=`(dst: var MyType; src: MyType) =
dst <- tmp
```
# move semantics
Move semantics mere introduced into c++ as a new way to construct objects. A move to `a` from `b` means that `a` get's contructed from `b`, but `a` may exploit `b` to do so. To support this feature C++ added two entirely new kinds of references to the language, to move reference, and the forward reference. One reference is marked as `&&T` and the other one `&&T`, but here T is a templated type. And then there is move initialization and move assignment.
Nim also needs some sort of move semantics, when it doesn't want to have everything garbage collected, but I do think that the c++ way of doing this is just too complicated, and for most cases unnecessary. The most important context for move optimization is the return value, because nobody wants create a complex copy operation that keeps the source object alive, just to delete this objects instantly after that. And to have move optimizations for return values, the language does not need to have additional move operations.
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.
Then the language would not need new features, it would just need to improve on already existing features.