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

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

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

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

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;
    }
}

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.

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?

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

>> 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

> 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