www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP68: Adding nogc to types

reply "Tomer Filiba" <tomerfiliba gmail.com> writes:
http://wiki.dlang.org/DIP68

This DIP proposes the addition of a compiler-enforced  nogc 
attribute on types. This means means such a type cannot be 
allocated by the GC, e.g., using operator new on such a type or 
appending such a type to a dynamic array, would result in 
compile-time errors.

It enforces separation between deterministic and 
non-deterministic finalization and lifetime of objects, which is 
crucial for proper RAII idiom.

For instance, suppose you require deterministic finalization of 
some resource, which is encapsulated by a struct whose destructor 
*must* be called. If your users could (accidentally?) create this 
object in the GC heap (e.g, holding it in an AA), you lose all 
RAII guarantees and break the code's assumptions.


-tomer
Nov 10 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Tomer Filiba:

 http://wiki.dlang.org/DIP68
Perhaps your DIP also needs a trait? struct Foo {} nogc struct Bar {} static assert(!__traits(hasNogc, Foo)); static assert(__traits(hasNogc, Bar)); Byem bearophile
Nov 10 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-11-10 14:58, bearophile wrote:

 Perhaps your DIP also needs a trait?
Don't we have something for that already? -- /Jacob Carlborg
Nov 10 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jacob Carlborg:

 Don't we have something for that already?
Do you mean we already have a trait for a feature that doesn't yet exists? :-) Bye, bearophile
Nov 10 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-11-10 20:19, bearophile wrote:

 Do you mean we already have a trait for a feature that doesn't yet
 exists? :-)
No, a trait or template to find out if a function is nogc. -- /Jacob Carlborg
Nov 10 2014
parent reply "Tomer Filiba" <tomerfiliba gmail.com> writes:
 No, a trait or template to find out if a function is  nogc.
__trait(getFunctionAttributes, F) -- but it returns flags that are applicable only to function attributes -tomer
Nov 11 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-11-11 14:19, Tomer Filiba wrote:

 __trait(getFunctionAttributes, F) -- but it returns flags that are
 applicable only to function attributes
Hmm, yeah. Using that trait on a type might be a bit weird. -- /Jacob Carlborg
Nov 11 2014
prev sibling next sibling parent "Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:
On Monday, 10 November 2014 at 12:59:14 UTC, Tomer Filiba wrote:
 http://wiki.dlang.org/DIP68

 This DIP proposes the addition of a compiler-enforced  nogc 
 attribute on types.
I would probably suggest extending this to variables. class Foo { nogc Bar var1; void doStuff() { nogc char* cStrPtr; } }
Nov 10 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/10/2014 4:59 AM, Tomer Filiba wrote:
 http://wiki.dlang.org/DIP68

 This DIP proposes the addition of a compiler-enforced  nogc attribute on types.
 This means means such a type cannot be allocated by the GC, e.g., using
operator
 new on such a type or appending such a type to a dynamic array, would result in
 compile-time errors.

 It enforces separation between deterministic and non-deterministic finalization
 and lifetime of objects, which is crucial for proper RAII idiom.

 For instance, suppose you require deterministic finalization of some resource,
 which is encapsulated by a struct whose destructor *must* be called. If your
 users could (accidentally?) create this object in the GC heap (e.g, holding it
 in an AA), you lose all RAII guarantees and break the code's assumptions.
I'm not at all sure that how a type is allocated should be part of the type itself. There are an infinite way things can be allocated.
Nov 10 2014
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Monday, 10 November 2014 at 20:00:51 UTC, Walter Bright wrote:
 I'm not at all sure that how a type is allocated should be part 
 of the type itself. There are an infinite way things can be 
 allocated.
Nitpick: it's about memory _management_, not _allocation_. But the DIP is also underspecified. E.g., is it allowed to embed a nogc type in a class? If not, what if that class again is wrapped in std.typecons.Scoped?
Nov 10 2014
parent "Tomer Filiba" <tomerfiliba gmail.com> writes:
 I'm not at all sure that how a type is allocated should be 
 part of the type itself. There are an infinite way things can 
 be allocated.
Nitpick: it's about memory _management_, not _allocation_.
Exactly. I don't care much *where* the object lives, as long as it has deterministic properties.
 But the DIP is also underspecified. E.g., is it allowed to 
 embed a  nogc type in a class? If not, what if that class again 
 is wrapped in std.typecons.Scoped?
I thought I covered it there, but just to be clear, nogc should be inherited by the containing type, so if a class has a nogc member, the class itself becomes nogc. For example: nogc struct Handle {...} class Mandle {Handle shmandle;} auto m1 = new Mandle(); // does not compile scoped!Mandle m2; // great success -tomer
Nov 11 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
I don't see the merit of this DIP and it clearly introduces whole 
new meaning of  nogc attribute (which needs a really good 
justification to pull it off)
Nov 11 2014
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Monday, 10 November 2014 at 12:59:14 UTC, Tomer Filiba wrote:
 http://wiki.dlang.org/DIP68
To be honest, I don't think that this DIP adds significant value to the language. Generally, you (as in a language/library implementor) need to assume that *any* struct with a non-trivial destructor relies on proper finalization anyway. Let's focus work on finally fixing bug 2834 instead. David
Nov 11 2014
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 11 November 2014 at 17:53:43 UTC, David Nadlinger 
wrote:
 Let's focus work on finally fixing bug 2834 instead.
(https://issues.dlang.org/show_bug.cgi?id=2834 – "Struct Destructors are not called by the GC, but called on explicit delete". To me, this seems to be the proper fix for your problem.)
Nov 11 2014
parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 11 November 2014 at 17:56:50 UTC, David Nadlinger 
wrote:
 On Tuesday, 11 November 2014 at 17:53:43 UTC, David Nadlinger 
 wrote:
 Let's focus work on finally fixing bug 2834 instead.
(https://issues.dlang.org/show_bug.cgi?id=2834 – "Struct Destructors are not called by the GC, but called on explicit delete". To me, this seems to be the proper fix for your problem.)
I would prefer to move away from calling destructors from the GC, and introducing finalizers instead, to clean up the confusion.
Nov 11 2014