digitalmars.D - DIP68: Adding nogc to types
- Tomer Filiba (15/15) Nov 10 2014 http://wiki.dlang.org/DIP68
- bearophile (8/9) Nov 10 2014 Perhaps your DIP also needs a trait?
- Jacob Carlborg (4/5) Nov 10 2014 Don't we have something for that already?
- bearophile (5/6) Nov 10 2014 Do you mean we already have a trait for a feature that doesn't
- Jacob Carlborg (4/6) Nov 10 2014 No, a trait or template to find out if a function is @nogc.
- Tomer Filiba (3/4) Nov 11 2014 __trait(getFunctionAttributes, F) -- but it returns flags that
- Jacob Carlborg (4/6) Nov 11 2014 Hmm, yeah. Using that trait on a type might be a bit weird.
- Chris Williams (8/11) Nov 10 2014 I would probably suggest extending this to variables.
- Walter Bright (3/14) Nov 10 2014 I'm not at all sure that how a type is allocated should be part of the t...
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (5/8) Nov 10 2014 Nitpick: it's about memory _management_, not _allocation_.
- Tomer Filiba (10/17) Nov 11 2014 I thought I covered it there, but just to be clear, @nogc should
- Dicebot (3/3) Nov 11 2014 I don't see the merit of this DIP and it clearly introduces whole
- David Nadlinger (7/8) Nov 11 2014 To be honest, I don't think that this DIP adds significant value
- David Nadlinger (5/6) Nov 11 2014 (https://issues.dlang.org/show_bug.cgi?id=2834 – "Struct
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (4/11) Nov 11 2014 I would prefer to move away from calling destructors from the GC,
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
Tomer Filiba:http://wiki.dlang.org/DIP68Perhaps 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
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
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
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
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
On 2014-11-11 14:19, Tomer Filiba wrote:__trait(getFunctionAttributes, F) -- but it returns flags that are applicable only to function attributesHmm, yeah. Using that trait on a type might be a bit weird. -- /Jacob Carlborg
Nov 11 2014
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
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
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
Exactly. I don't care much *where* the object lives, as long as it has deterministic properties.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?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
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
On Monday, 10 November 2014 at 12:59:14 UTC, Tomer Filiba wrote:http://wiki.dlang.org/DIP68To 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
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
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:I would prefer to move away from calling destructors from the GC, and introducing finalizers instead, to clean up the confusion.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