http://wiki.dlang.org/DIP60

Start on implementation:

https://github.com/D-Programming-Language/dmd/pull/3455

Walter Bright:

> http://wiki.dlang.org/DIP60

Given the current strong constraints in the directions of D design, I like it.

But in DIPs I suggest to also write a list of the advantages of a proposal, and a list of all the disadvantages.

In this ER I suggested a @noheap, that is meant to also forbid the C memory allocation functions:
https://issues.dlang.org/show_bug.cgi?id=5219
But I guess there is no reliable way to catch those function calls too?
If the discussion is against @noheap then I'll close that ER as obsolete.

With @nogc D has most of the basic function effects covered. One missing effect that D is not yet putting under control is nontermination; to annotate functions that can not loop forever and never return (like a function with an infinite loop inside, etc). But for the kind of programs written in D, I presume this effect is not yet important enough to deserve an annotation like @terminates.

There is a language studied by Microsoft that faces the problem of effects algebra in a more discipled and high-level way. I don't know how much this can help D at its current development stage:
http://research.microsoft.com/en-us/projects/koka/
But in general reading research papers is useful to get in a good mindframe.
In Koka language the functions that can not terminate are annotated with "div", that means "divergence". But Koka has a good effect inference.

Bye,
bearophile

On Tue, 15 Apr 2014 13:01:40 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> http://wiki.dlang.org/DIP60'

Wow, that's quite underspecified.

What about syscalls? Nothrow functions allow one to call non-nothrow functions, but catch all exceptions. What if you want to use the GC for allocation temporarily, and then delete all the usage before returning? Must you use C malloc/free? What about such code that is @safe, which cannot call free?

Off the top of my head...

-Steve

On 4/15/2014 11:41 AM, Steven Schveighoffer wrote:
> On Tue, 15 Apr 2014 13:01:40 -0400, Walter Bright <newshound2@digitalmars.com>
> wrote:
>
>> http://wiki.dlang.org/DIP60'
>
> Wow, that's quite underspecified.

Ok, but I don't see how.


> What about syscalls?

Not sure what you mean by that, but obviously Windows API functions would be @nogc.


> Nothrow functions allow one to call non-nothrow functions,
> but catch all exceptions. What if you want to use the GC for allocation
> temporarily, and then delete all the usage before returning?

@nogc doesn't allow an escape from it. That's the point of it.


> Must you use C malloc/free?

If you can GC/GCfree, then you can use malloc/free.


> What about such code that is @safe, which cannot call free?

There's no point to @nogc if you can still call the GC in it.

On Tue, 15 Apr 2014 14:58:25 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/15/2014 11:41 AM, Steven Schveighoffer wrote:
>> On Tue, 15 Apr 2014 13:01:40 -0400, Walter Bright <newshound2@digitalmars.com>
>> wrote:
>>
>>> http://wiki.dlang.org/DIP60'
>>
>> Wow, that's quite underspecified.
>
> Ok, but I don't see how.

i.e. the rest of my post.

>> What about syscalls?
>
> Not sure what you mean by that, but obviously Windows API functions would be @nogc.

Linux syscalls are not Windows API, they are extern(C) calls. Basically, we will have to mark most as @nogc, right? or are extern(C) calls automatically considered @nogc?

>> Nothrow functions allow one to call non-nothrow functions,
>> but catch all exceptions. What if you want to use the GC for allocation
>> temporarily, and then delete all the usage before returning?
>
> @nogc doesn't allow an escape from it. That's the point of it.

My point:

void foo1() {throw new Exception("hi");}

void foo2() nothrow { try {foo1();} catch(Exception e) {} }

This is valid.

int isthisok(int x, int y) @nogc
{
   // need scratch space
   int[] buf = new int[x * y];
   scope(exit) GC.free(buf.ptr);
   // perform some algorithm using buf
   ...
   //
   return buf[$-1];
}

Valid?

>> Must you use C malloc/free?
>
> If you can GC/GCfree, then you can use malloc/free.

What if you can't use GC/GCfree? i.e. @nogc (the point of this thread)

>> What about such code that is @safe, which cannot call free?
>
> There's no point to @nogc if you can still call the GC in it.

This is a follow-on to the previous question. Let's say you cannot use GC, but clearly, I can use C malloc/free. Safe code that needs arbitrary buffers must use C malloc/free to manage them, but safe cannot legally call free.

I think we would need some sort of scoped allocator to make life bearable.

-Steve

On Tue, 15 Apr 2014 14:41:36 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On Tue, 15 Apr 2014 13:01:40 -0400, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> http://wiki.dlang.org/DIP60'
>
> Wow, that's quite underspecified.

What specifically is prevented? GC.malloc, GC.free, clearly. What about GC.getAttr? GC.query? These will not invoke collection cycles (the point of @nogc).

Actually, maybe just fullcollect is the root @nogc method...

In any case, more concrete details should be specified in the DIP.

-Steve

On Tue, 15 Apr 2014 15:14:47 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> Actually, maybe just fullcollect is the root @nogc method...

Said that wrong, fullcollect is the base method you cannot mark as @nogc.

-Steve

On Tuesday, 15 April 2014 at 19:12:30 UTC, Steven Schveighoffer wrote:
> int isthisok(int x, int y) @nogc
> {
>    // need scratch space
>    int[] buf = new int[x * y];
>    scope(exit) GC.free(buf.ptr);
>    // perform some algorithm using buf
>    ...
>    //
>    return buf[$-1];
> }
>
> Valid?

No way. This can trigger GC collection. @nogc is not about observable pre- and post- state but about prohibiting specific operation completely.

On 4/15/2014 12:12 PM, Steven Schveighoffer wrote:
>>> What about syscalls?
>>
>> Not sure what you mean by that, but obviously Windows API functions would be
>> @nogc.
>
> Linux syscalls are not Windows API, they are extern(C) calls. Basically, we will
> have to mark most as @nogc, right?

Right, just like nothrow.


> or are extern(C) calls automatically considered @nogc?

No, just like for nothrow.


> int isthisok(int x, int y) @nogc
> {
>     // need scratch space
>     int[] buf = new int[x * y];
>     scope(exit) GC.free(buf.ptr);
>     // perform some algorithm using buf
>     ...
>     //
>     return buf[$-1];
> }
>
> Valid?

No.


>>> Must you use C malloc/free?
>>
>> If you can GC/GCfree, then you can use malloc/free.
>
> What if you can't use GC/GCfree? i.e. @nogc (the point of this thread)

Then use malloc/free.


>>> What about such code that is @safe, which cannot call free?
>>
>> There's no point to @nogc if you can still call the GC in it.
>
> This is a follow-on to the previous question. Let's say you cannot use GC, but
> clearly, I can use C malloc/free. Safe code that needs arbitrary buffers must
> use C malloc/free to manage them, but safe cannot legally call free.

That's why @trusted exists.


> I think we would need some sort of scoped allocator to make life bearable.

    p = malloc(...);
    scope(exit) free(p);

Let's be clear about the motivation for @nogc - there are a lot of people who will not use D because of fear of GC. They want a guarantee that the GC isn't being called. They don't want code that hides calls to GC.

On 4/15/2014 12:14 PM, Steven Schveighoffer wrote:
> On Tue, 15 Apr 2014 14:41:36 -0400, Steven Schveighoffer <schveiguy@yahoo.com>
> wrote:
>
>> On Tue, 15 Apr 2014 13:01:40 -0400, Walter Bright <newshound2@digitalmars.com>
>> wrote:
>>
>>> http://wiki.dlang.org/DIP60'
>>
>> Wow, that's quite underspecified.
>
> What specifically is prevented?

All calls to the GC.