On Tuesday, 15 April 2014 at 19:56:46 UTC, Walter Bright wrote:
> On 4/15/2014 12:49 PM, Tove wrote:
>> Yes, please all, even "harmless" calls. This way you are guaranteed that you can
>> include @nogc modules in projects which doesn't even link with a GC.
>
> Yup.

One issue we might encounter, is that when a function requires a local temporary buffer, then "@nogc" and "pure" will be mutually exclussive. Implementation can either use the GC, and be pure but not @nogc. Or it can use malloc, and no @nogc but impure.

I recently worked on a more generic version of your "ScopeBuffer", "ScopeAppender", which makes some concessions to be usable in a more generic fashion. It uses the GC, even though it retains complete ownership of the allocated data, if only just to be useable in pure code.

So, yeah. That might be a problem for those that want to do without the GC, but retain purity.

On 4/15/2014 1:19 PM, monarch_dodra wrote:
> On Tuesday, 15 April 2014 at 20:13:19 UTC, Walter Bright wrote:
>> On 4/15/2014 1:10 PM, H. S. Teoh via Digitalmars-d wrote:
>>> Is automatic inference of @nogc anywhere within our reach right now?
>>
>> Yes, it's no harder than pure or nothrow inference is.
>
> I meant mostly for non-template code, where there is no inference.

I had a PR for that, but nobody liked it.

On 4/15/2014 1:25 PM, monarch_dodra wrote:
> So, yeah. That might be a problem for those that want to do without the GC, but
> retain purity.

There are ways to cheat if you must.

On 4/15/2014 1:37 PM, Walter Bright wrote:
> On 4/15/2014 1:19 PM, monarch_dodra wrote:
>> On Tuesday, 15 April 2014 at 20:13:19 UTC, Walter Bright wrote:
>>> On 4/15/2014 1:10 PM, H. S. Teoh via Digitalmars-d wrote:
>>>> Is automatic inference of @nogc anywhere within our reach right now?
>>>
>>> Yes, it's no harder than pure or nothrow inference is.
>>
>> I meant mostly for non-template code, where there is no inference.
>
> I had a PR for that, but nobody liked it.

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

On Tue, 15 Apr 2014 15:20:41 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

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

The DIP should be clear on this. Right now it says "guarantee code will not allocate using GC"

I now understand the rationale, and intended result. All that is left to specify is the implementation (who does what).

-Steve

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

> On 4/15/2014 12:14 PM, Steven Schveighoffer wrote:
>> 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).
>
> All functions not marked as @nogc cannot be called from a @nogc function. GC.malloc(), etc., are functions.
>
> It works very much analogously to nothrow.
>

right, but at the end of the day, nothrow doesn't allow throw statements. @nogc, so far, just doesn't allow you to call other functions that aren't marked @nogc. There is no primitive that is not allowed (I assume new isn't allowed, but you can access the GC other ways).

These requirements, or assumptions, need to be documented.

-Steve

On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
> http://wiki.dlang.org/DIP60
>
> Start on implementation:
>
> https://github.com/D-Programming-Language/dmd/pull/3455


"GC allocations in a @nogc function will be disallowed, and that means calls to operator new"

I do not think new is exclusive to GC? It can be overridden. If new is overridden by classes and marked @nogc then it too should be allowed.

e.g., new, slices, array behavior, even all the GC methods themselves, are all not necessarily dependent on the GC if their behavior can be overridden not to use the GC.

Essentially all default GC dependent behavior should be marked @gc and all default non-GC dependent behavior should be marked @nogc. User defined behavior could be marked either way except @nogc behavior can't use @gc behavior.

After all, @nogc is just an attribute and means nothing except what is prescribed to it(you could mark all the GC's functions as @nogc and then use them in @nogc code if you want, which, of course, defeats the whole purpose).

I just hope that if implemented, it is not blindly done so that prevents one from accurately removing GC dependence(which is the whole point of having the attribute).

On 4/15/2014 1:42 PM, Frustrated wrote:
> I do not think new is exclusive to GC? It can be overridden.

Global operator new is not overridable.


> If new is overridden by classes and marked @nogc then it too should be allowed.

Then they are treated as regular functions - they'd have to be marked as @nogc to be used in @nogc functions.


> e.g., new, slices, array behavior, even all the GC methods themselves, are all
> not necessarily dependent on the GC if their behavior can be overridden not to
> use the GC.

Overrides use functions, and then the behavior depends on how those functions are annotated.


> I just hope that if implemented, it is not blindly done so that prevents one
> from accurately removing GC dependence(which is the whole point of having the
> attribute).

I don't know what you mean by this.

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

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

Additional proposal:

In non-release mode, at the start of @nogc function, a thread-local variable __nogc is incremented. At the end, __nogc is decremented. Then if any GC calls occur when __nogc is nonzero, an error is thrown.

This would be for debugging only, and I'm thinking specifically to prove absolutely no hidden compiler-generated GC calls, or calls via extern(C) functions occur.

-Steve

On 4/15/2014 1:41 PM, Steven Schveighoffer wrote:
> right, but at the end of the day, nothrow doesn't allow throw statements. @nogc,
> so far, just doesn't allow you to call other functions that aren't marked @nogc.

"GC allocations in a @nogc function will be disallowed, and that means calls to operator new, closures that allocate on the GC, array concatenation, array appends, and some array literals."