On Monday, 25 July 2016 at 00:05:16 UTC, ketmar wrote:
> On Sunday, 24 July 2016 at 23:30:37 UTC, bitwise wrote:
>> On Sunday, 24 July 2016 at 23:10:18 UTC, Dicebot wrote:
>>> @nogc functions must never ever trigger GC collection cycle, not under any possible circumstances. Otherwise the attribute serves no purpose.
>>
>> The fact that you can use malloc() in a @nogc function invalidates this argument.
>
> nope. `malloc()` has nothing to do with garbage collection.
>
> what `@nogc` means is "i won't use built-in allocator with garbage collection in this code", not "i won't do any memory allocations in this code".

If someone knows all their code is @nogc, they can disable the GC. If they do that, and then someone GC allocates anyways, it's a leak. Based on this, an argument could be made that @nogc should *never* be bypassed. But that argument is made on the false premise that it's fool-proof in it's current condition. It's not, because you can already use malloc() in a @nogc function and leak that memory instead.

     Bit

On Monday, 25 July 2016 at 00:26:05 UTC, bitwise wrote:
> If someone knows all their code is @nogc, they can disable the GC. If they do that, and then someone GC allocates anyways, it's a leak. Based on this, an argument could be made that @nogc should *never* be bypassed. But that argument is made on the false premise that it's fool-proof in it's current condition. It's not, because you can already use malloc() in a @nogc function and leak that memory instead.

`@nogc` should not be bypassed due to completely different reasons. while compiler is not doing any optimizations or generating any GC helpers for gc code now, it *can* do that in the future, so cheating the compiler is bad idea.

otherwise, `@nogc` doesn't really guarantee absence of memory leaks, and it wasn't designed to do so.

On 25/07/2016 10:13 AM, bitwise wrote:
> Any thoughts on an @gc attribute for bypassing @nogc?
>
> As much as I like to cringe at the GC when I'm using C#, I can't ignore
> my level of productivity, as it compares to projects I've done in C++.
>
> If I had to write a butter-smooth AAA game, it may be a problem, but at
> present, my thoughts on a few small jitters here and there are....who
> cares?
>
> As long as GC usage is kept to a minimum, things will usually work ok fine.
>
> For example, in a game, I may create a script with an "update" method
> that gets called each frame. I wouldn't want people(or myself)
> accidentally allocating memory here, possible 30-60 times per second, so
> I would  make that function @nogc. But, there *will* be cases where I
> actually want to allocate something, for example, to spawn a piece of cake.
>
> Example:
>
> class Cake{}
>
> class MyScript {
>     SysTime when;
>     this() { when = Clock.currTime + 5.seconds; }
>     void update() @nogc {
>         // ...
>         if(Clock.currTime >= when) {
>             @gc {
>                 Cake c = new Cake();
>             }
>         }
>     }
> }
>
> void main(string[] args) {
>     MyScript script = new MyScript();
>
>     foreach(i; 0..10) {
>         script.update();
>         Thread.sleep(1.seconds);
>     }
> }
>
> There is the following, which is clever. But if it came down to having
> to do this to bypass @nogc, I simply wouldn't use @nogc.
>
> https://p0nce.github.io/d-idioms/#Bypassing-@nogc
>
> When you have to do it thousands of times throughout your codebase, then
> yes, it's that bad.
>
>     Bit
>

I've been saying for a very long time we need @assumenogc attribute like we have @trusted for @safe.
I have not been taken very seriously about this...

Although I see no reason to allow GC in @assumenogc as long as it does not trigger scan/collect phase of it. After all, why don't we have a hint on allocation if we do or do not want it to trigger a scan?

Or even better, a thread local stack to specify this!

On Monday, 25 July 2016 at 03:18:17 UTC, rikki cattermole wrote:
> On 25/07/2016 10:13 AM, bitwise wrote:
>>[...]
>
> I've been saying for a very long time we need @assumenogc attribute like we have @trusted for @safe.

I havent seen this assumegc propsal before, could you provide the definition you had in mind for it?

> I have not been taken very seriously about this...
>
> Although I see no reason to allow GC in @assumenogc as long as it does not trigger scan/collect phase of it. After all, why don't we have a hint on allocation if we do or do not want it to trigger a scan?

If the GC supported this mode (NoCollectionMode), what should the GC do when it is in this mode and an allocation is requested that can't be done until a collection is done?

On 25/07/2016 5:16 PM, Jonathan Marler wrote:
> On Monday, 25 July 2016 at 03:18:17 UTC, rikki cattermole wrote:
>> On 25/07/2016 10:13 AM, bitwise wrote:
>>> [...]
>>
>> I've been saying for a very long time we need @assumenogc attribute
>> like we have @trusted for @safe.
>
> I havent seen this assumegc propsal before, could you provide the
> definition you had in mind for it?

I've mostly kept it off hand for other regulars as I'm not really the best person to run with it and make it happen.

>> I have not been taken very seriously about this...
>>
>> Although I see no reason to allow GC in @assumenogc as long as it does
>> not trigger scan/collect phase of it. After all, why don't we have a
>> hint on allocation if we do or do not want it to trigger a scan?
>
> If the GC supported this mode (NoCollectionMode), what should the GC do
> when it is in this mode and an allocation is requested that can't be
> done until a collection is done?

Fail.
On Linux this should almost never happen and Windows should in theory be the same way.

On Monday, 25 July 2016 at 07:43:34 UTC, rikki cattermole wrote:
> I've been saying for a very long time we need @assumenogc attribute like we have
> @trusted for @safe.

So I'm not crazy then ;)

I'm wondering if Andrei and Walter consider @trusted a win though. They seem to have such firm stances on certain issues that it makes me wonder if they consider things like @trusted a liability.

Personally, I lean way to the side of flexibility, and believe a good language shouldn't force you to code a certain way(within reason). I feel like this type of feature is very reasonable.

    Bit

On Mon, 25 Jul 2016 15:46:54 +0000, bitwise wrote:

> On Monday, 25 July 2016 at 07:43:34 UTC, rikki cattermole wrote:
>> I've been saying for a very long time we need @assumenogc attribute like we have @trusted for @safe.
> 
> So I'm not crazy then ;)
> 
> I'm wondering if Andrei and Walter consider @trusted a win though. They seem to have such firm stances on certain issues that it makes me wonder if they consider things like @trusted a liability.
> 
> Personally, I lean way to the side of flexibility, and believe a good language shouldn't force you to code a certain way(within reason). I feel like this type of feature is very reasonable.
> 
>      Bit

@nogc conflates "doesn't allocate memory from the GC heap because I don't want my application to use the GC at all" with "doesn't cause GC collection pauses".

The latter can have a @assumenogc annotation that works -- you call GC.disable and GC.enable as appropriate. The former can't.

On Tuesday, 26 July 2016 at 01:07:27 UTC, Chris Wright wrote:
> On Mon, 25 Jul 2016 15:46:54 +0000, bitwise wrote:
>
>> On Monday, 25 July 2016 at 07:43:34 UTC, rikki cattermole wrote:
>>> I've been saying for a very long time we need @assumenogc attribute like we have @trusted for @safe.
>> 
>> So I'm not crazy then ;)
>> 
>> I'm wondering if Andrei and Walter consider @trusted a win though. They seem to have such firm stances on certain issues that it makes me wonder if they consider things like @trusted a liability.
>> 
>> Personally, I lean way to the side of flexibility, and believe a good language shouldn't force you to code a certain way(within reason). I feel like this type of feature is very reasonable.
>> 
>>      Bit
>
> @nogc conflates "doesn't allocate memory from the GC heap because I don't want my application to use the GC at all" with "doesn't cause GC collection pauses".
>
> The latter can have a @assumenogc annotation that works -- you call GC.disable and GC.enable as appropriate. The former can't.

Fair point.

You got me thinking though. For my intended usage, I don't actually need errors for GC allocation, and that may actually be inappropriate. I just need to make a best effort to avoid allocations.

Something like @warngc could work nicely. It could function exactly as @nogc with the exception that it issued warnings instead of errors.

I feel like some people reading this would be very quick to scold me for "premature optimization", and recommend a profiler, but in the case of 30-60 fps games, it's practically guaranteed that you will eventually run into performance problems. Especially on mobile devices. So proactively writing good code can save you a lot of headache.

    Bit

On Tuesday, 26 July 2016 at 02:42:52 UTC, bitwise wrote:
> Something like @warngc could work nicely. It could function exactly as @nogc with the exception that it issued warnings instead of errors.

i don't think that it will be added, though. but you can emulate it with external utility: either with dscanner (writing your own linter), or with "-vgc" and then using simple regexp to find in which function the reported line is in. somewhat messy, but it is the way to get the work done without waiting for new attr. ;-)

p.s. probably even with -vgc to list line numbers and dscanner to find function names/signatures. "-vgc" has the advantage of reporting closuses, while with "handmade" linter you'll have to track that by yourself.