On Wednesday, 16 April 2014 at 02:14:18 UTC, Walter Bright wrote:
> On 4/15/2014 6:57 PM, Mike wrote:
>> I suspect some of the motivation for this is to give customers "faster horses".
>> I would be surprised if a @nogc attribute increased D's appeal, and I think
>> efforts would be better allocated to some form of the above.
>
> Asking for @nogc comes up *constantly*.

I know it does, but users employing @nogc still have to manage memory somehow.  Let's add hooks to the runtime and implement some GC alternatives, and then see what demand is like ;-)

> I know it does, but users employing @nogc still have to manage memory somehow.  Let's add hooks to the runtime and implement some GC alternatives, and then see what demand is like ;-)


 They use noGC and smart pointers/manual ala C++.

 You seem to be suggesting that people who don't want GC, actually secretly want GC. Just to let you know, that isn't the case. A global one size fits all approach to memory management is far from optimal.

On Tuesday, 15 April 2014 at 21:42:51 UTC, Walter Bright wrote:
> On 4/15/2014 2:41 PM, Brad Anderson wrote:
>> Yes, please. Too few of the attributes have inverse attributes.
>
> That's a subject for another DIP.

This would go fairly well with Andrei's idea of passing true or false to an attribute to enable or disable it.

@gc(false) void fun() {}

Also, as was mentioned earlier in the thread, if @gc was actually implemented as a UDA just like any other, gc could simply be a struct that the compiler looks for, something along those lines.

struct gc
{
    bool enable;
    //...
}

Which naturally implements Andrei's proposed syntax. The same could be done for @property, @safe, etc. If we had DMD as a library, @gc probably wouldn't even need to be "special", i.e., compiler magic.

Finally, as MonarchDodra mentioned, the number of optional attributes to mark a function with can get to be a problem after awhile. I have two ideas on this. One is extending the concept of aliases to also alias attributes, like so:

//TypeTuple or just bare list?
alias everything = TypeTuple!(@safe, nothrow, pure, @gc(false));

or

alias everything(Attrs...) = Attrs;

I think that the Microsoft language with effect algebra (Bearophile has mentioned it before) does this. E.g., pure is actually:
alias pure: noeffects nothrow //... (I don't remember the actual syntax)

Secondly, this could just be a "higher level attribute". I don't know if this would require a language change or not...

struct Everything
{
    bool _pure;
    bool _nothrow;
    //...
}

Meta:

> //TypeTuple or just bare list?
> alias everything = TypeTuple!(@safe, nothrow, pure, @gc(false));
>
> or
>
> alias everything(Attrs...) = Attrs;
>
> I think that the Microsoft language with effect algebra (Bearophile has mentioned it before) does this. E.g., pure is actually:
> alias pure: noeffects nothrow //... (I don't remember the actual syntax)

In Koka those are not lists but sets of effects.

Bye,
bearophile

On Wednesday, 16 April 2014 at 03:58:08 UTC, bearophile wrote:
> Meta:
>
>> //TypeTuple or just bare list?
>> alias everything = TypeTuple!(@safe, nothrow, pure, @gc(false));
>>
>> or
>>
>> alias everything(Attrs...) = Attrs;
>>
>> I think that the Microsoft language with effect algebra (Bearophile has mentioned it before) does this. E.g., pure is actually:
>> alias pure: noeffects nothrow //... (I don't remember the actual syntax)
>
> In Koka those are not lists but sets of effects.
>
> Bye,
> bearophile

Yes, but it's similar to the Koka concept, adapted for D. Perhaps D could lift the concept from Koka without any changes, I don't know.

On Wednesday, 16 April 2014 at 03:16:34 UTC, froglegs wrote:
>
>> I know it does, but users employing @nogc still have to manage memory somehow.  Let's add hooks to the runtime and implement some GC alternatives, and then see what demand is like ;-)
>
>
>  They use noGC and smart pointers/manual ala C++.

Yes, and they would have to forego many of D's features that do implicit allocations (dynamic arrays, exceptions, etc...) and implement alternatives.

If the right hooks and corresponding logic were added to the runtime, users could potentially implement memory management alternatives, including some which more closely mimic that of C++, and still be able to employ those features.

>
>  You seem to be suggesting that people who don't want GC, actually secretly want GC. Just to let you know, that isn't the case.

No, I'm not.  I'm suggesting people who say they don't want GC want an alternative way to manage memory.  So I suggest adding runtime hooks that would enable us to build alternatives.

I suggest adding a way to override a @nogc function for debugging purposes:

suppose we need to *temporarily* debug / instrument a function marked as @nogc (myfun) by adding some piece of code that may allocate (quick and dirty debugging). Unfortunately, in DIP60 we can't just temporarily remove the @nogc attribute as myfun may be called by many other @nogc functions and changing all those attributes would be too complex.

With the propose override, we can just recompile with a flag ; how to do that is implementation detail but here's an option:

dmd -allow_gc_in_nogc fun.d

@nogc myfun(){

//temporary for debugging/instrumentation
@gc{
//code that can allocate
}

}



On Tue, Apr 15, 2014 at 10:01 AM, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> http://wiki.dlang.org/DIP60
>
> Start on implementation:
>
> https://github.com/D-Programming-Language/dmd/pull/3455
>

On 4/15/14, 12:18 PM, Dicebot wrote:
> 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.

Very nice. This is a preemptive close of an entire class of arguments. -- Andrei

On Wednesday, 16 April 2014 at 03:26:24 UTC, Meta wrote:
> This would go fairly well with Andrei's idea of passing true or false to an attribute to enable or disable it.
>
> @gc(false) void fun() {}
>

I don't like this because it's hard to read. It's a bad idea. Never use booleans in interfaces like that. @gc and @nogc are better.

On Tuesday, 15 April 2014 at 23:54:24 UTC, Matej Nanut via Digitalmars-d wrote:
> This shouldn't be a problem if you plonk @nogc: at the top of your own file, as it won't compile anymore if you try to call @gc functions.

It is a problem if you are allowed to override @nogc with @gc, which is what the post I responded to suggested.