www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Nim - Introducing --gc:arc

reply JN <666total wp.pl> writes:
Some folks may find it interesting, Nim is introducing a new 
memory management scheme:

"So ... this feature has been in development for quite some time 
now, Nim is getting the "one GC to rule them all". However 
calling it a GC doesn't do it justice, it's plain old reference 
counting with optimizations thanks to move semantics."

https://forum.nim-lang.org/t/5734
Dec 25 2019
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 26 December 2019 at 01:27:01 UTC, JN wrote:

 Some folks may find it interesting, Nim is introducing a new 
 memory management scheme:


Nim suddenly got a lot more attractive. Interesting move. Still 
in beta?

I wonder how they deal with sharing slices of arrays across 
threads?
I guess one could use some kind of wrapper.
Dec 25 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/25/2019 5:27 PM, JN wrote:

 Some folks may find it interesting, Nim is introducing a new memory management 
 scheme:
 
 "So ... this feature has been in development for quite some time now, Nim is 
 getting the "one GC to rule them all". However calling it a GC doesn't do it 
 justice, it's plain old reference counting with optimizations thanks to move 
 semantics."
 
 https://forum.nim-lang.org/t/5734


D gave up on ARC for the time being because it was too easy to free an ARC 
object while retaining a live pointer to its innards (as pointed out by Timon 
Gehr). The solution to this is ownership/borrowing, which I am working on.
Dec 26 2019
next sibling parent reply user7892 <user7892 vlognet.ch> writes:
On Friday, 27 December 2019 at 02:30:32 UTC, Walter Bright wrote:

 On 12/25/2019 5:27 PM, JN wrote:

 Some folks may find it interesting, Nim is introducing a new 
 memory management scheme:
 
 "So ... this feature has been in development for quite some 
 time now, Nim is getting the "one GC to rule them all". 
 However calling it a GC doesn't do it justice, it's plain old 
 reference counting with optimizations thanks to move 
 semantics."
 
 https://forum.nim-lang.org/t/5734


 D gave up on ARC for the time being because it was too easy to 
 free an ARC object while retaining a live pointer to its 
 innards (as pointed out by Timon Gehr). The solution to this is 
 ownership/borrowing, which I am working on.


I have the feeling that their ARC is more like if in D you'd pass 
the arg to the compiler and then at compile another family of 
template hooks from druntime would be used.

Is that the plan to in D or people will have to mix the two 
worlds ?
Dec 26 2019
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 27 December 2019 at 06:27:42 UTC, user7892 wrote:

 I have the feeling that their ARC is more like if in D you'd 
 pass the arg to the compiler and then at compile another family 
 of template hooks from druntime would be used.


Araq said in the thread that they hope for production quality in 
a few months and to make ARC the default.
Dec 27 2019
prev sibling parent NaN <divide by.zero> writes:
On Friday, 27 December 2019 at 02:30:32 UTC, Walter Bright wrote:

 On 12/25/2019 5:27 PM, JN wrote:

 Some folks may find it interesting, Nim is introducing a new 
 memory management scheme:
 
 "So ... this feature has been in development for quite some 
 time now, Nim is getting the "one GC to rule them all". 
 However calling it a GC doesn't do it justice, it's plain old 
 reference counting with optimizations thanks to move 
 semantics."
 
 https://forum.nim-lang.org/t/5734


 D gave up on ARC for the time being because it was too easy to 
 free an ARC object while retaining a live pointer to its 
 innards (as pointed out by Timon Gehr). The solution to this is 
 ownership/borrowing, which I am working on.


Could you elaborate a bit more? IIRC its been said that 
ownership/borrowing is only for safe code? So will ARC only work 
in safe code too?
Dec 27 2019