On Tuesday, 19 September 2017 at 20:57:17 UTC, Neia Neutuladh wrote:
> On Tuesday, 19 September 2017 at 15:11:31 UTC, Craig Black wrote:
>> [...]
>
> You want to ensure that it can never refer to GC memory. The type system does not contain that information. It doesn't say whether an object was allocated on the GC heap, on the stack, using malloc, using a whole page of memory with mmap, using hardware addresses directly on an embedded system with manually planned memory layout, using a well-known address range like VGA, as part of the binary's static data segment...
>
> [...]

Thank you for the information. I hadn't thought of using templates like that.  That might accomplish what I'm trying to do.  Much appreciated!

-Craig

On Tuesday, 19 September 2017 at 13:11:03 UTC, Craig Black wrote:
> I've recently tried coding in D again after some years.  One of my earlier concerns was the ability to code without the GC, which seemed difficult to pull off.  To be clear, I want my programs to be garbage collected, but I want to use the GC sparingly so that the mark and sweep collections will be fast.  So I want guarantees that certain sections of code and certain structs will not require the GC in any way.
>
> I realize that you can allocate on the non-GC heap using malloc and free and emplace, but I find it troubling that you still need to tell the GC to scan your allocation. What I would like is, for example, to be able to write a @nogc templated struct that guarantees that none of its members require GC scanning.  Thus:
>
> @nogc struct Array(T)
> {
>   ...
> }
>
> class GarbageCollectedClass
> {
> }
>
> void main()
> {
>   Array!int intArray; // fine
>
>
> }

I've implemented data annotation in iz, if you want to take a look.
It's quite near from what you descibed in a more recent answer:

----
/+ dub.sdl:
   name "dub_script"
   dependency "iz" version="0.6.0"
+/
module dub_script;

import iz.memory;

// defines a class that has a member
// which is usually handled by the GC
class Foo {void* looks_gc_managed;}
// defines a class and marks member as nogc-"trusted"
class Bar {@NoGc Foo foo;}
// defines a class without annotation
class Baz {Foo foo;}

// verified statically
static assert(!MustAddGcRange!Bar);
static assert( MustAddGcRange!Baz);

void main(string[] args)
{
    Foo foo = construct!Foo;
    destruct(foo);
}
----

It's another way of doing things. It's less strict than checking all the functions.

note: the script can be run directly by passing the file to DUB (single file package).

On Wednesday, 20 September 2017 at 02:43:44 UTC, B4s1L3 wrote:
> On Tuesday, 19 September 2017 at 13:11:03 UTC, Craig Black wrote:
>> I've recently tried coding in D again after some years.  One of my earlier concerns was the ability to code without the GC, which seemed difficult to pull off.  To be clear, I want my programs to be garbage collected, but I want to use the GC sparingly so that the mark and sweep collections will be fast.
>>  So I want guarantees that certain sections of code and certain structs will not require the GC in any way.
>>
>> I realize that you can allocate on the non-GC heap using malloc and free and emplace, but I find it troubling that you still need to tell the GC to scan your allocation. What I would like is, for example, to be able to write a @nogc templated struct that guarantees that none of its members require GC scanning.  Thus:
>>
>> @nogc struct Array(T)
>> {
>>   ...
>> }
>>
>> class GarbageCollectedClass
>> {
>> }
>>
>> void main()
>> {
>>   Array!int intArray; // fine
>>
>>
>> }
>
> I've implemented data annotation in iz, if you want to take a look.
> It's quite near from what you descibed in a more recent answer:
>
> ----
> /+ dub.sdl:
>    name "dub_script"
>    dependency "iz" version="0.6.0"
> +/
> module dub_script;
>
> import iz.memory;
>
> // defines a class that has a member
> // which is usually handled by the GC
> class Foo {void* looks_gc_managed;}
> // defines a class and marks member as nogc-"trusted"
> class Bar {@NoGc Foo foo;}
> // defines a class without annotation
> class Baz {Foo foo;}
>
> // verified statically
> static assert(!MustAddGcRange!Bar);
> static assert( MustAddGcRange!Baz);
>
> void main(string[] args)
> {
>     Foo foo = construct!Foo;
>     destruct(foo);
> }
> ----
>
> It's another way of doing things. It's less strict than checking all the functions.
>
> note: the script can be run directly by passing the file to DUB (single file package).

Wow!  Yeah that seems like almost exactly what I want. Sorry what is iz?  Thank you!

-Craig

On Wednesday, 20 September 2017 at 02:43:44 UTC, B4s1L3 wrote:
> It's another way of doing things. It's less strict than checking all the functions.
>
> note: the script can be run directly by passing the file to DUB (single file package).


Wow!  Yeah that seems like almost exactly what I want. Sorry what is iz?  Thank you!

-Craig

On Wednesday, 20 September 2017 at 16:13:44 UTC, Craig Black wrote:
> On Wednesday, 20 September 2017 at 02:43:44 UTC, B4s1L3 wrote:
>> It's another way of doing things. It's less strict than checking all the functions.
>>
>> note: the script can be run directly by passing the file to DUB (single file package).
>
>
> Wow!  Yeah that seems like almost exactly what I want. Sorry what is iz?  Thank you!
>
> -Craig

It's a D user library: https://github.com/BBasile/iz.

I forgot to say but the @NoGc data annotation relies on construct(). Neither `new` not `std.experimental.allocator.make` are usable, because `AddGcRoot()`, when needed, is called inside `construct` (which is, if you remove the ability to handle the annotation, similar to make).