April 15, 2014
On Tuesday, 15 April 2014 at 19:40:50 UTC, Walter Bright wrote:
> 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.

What about GC calls that cannot cause a collection? Do they even exist?
April 15, 2014
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.

April 15, 2014
On Tuesday, 15 April 2014 at 19:44:39 UTC, John Colvin wrote:
> On Tuesday, 15 April 2014 at 19:40:50 UTC, Walter Bright wrote:
>> 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.
>
> What about GC calls that cannot cause a collection? Do they even exist?

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.
April 15, 2014
On 4/15/2014 12:44 PM, John Colvin wrote:
> What about GC calls that cannot cause a collection? Do they even exist?

All functions not marked as @nogc cannot be called from @nogc functions.

Of course, the person adding @nogc attributes to code inside the GC had better know what they're doing.
April 15, 2014
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.
April 15, 2014
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

I have an issue related to adding an extra attribute: Attributes of non-template functions. Currently, you have to mark most functions as already pure, nothrow and @safe. If we are adding another attribute. Code will start looking alike this:

int someTrivialFunction(int i) @safe pure nothrow @nogc;

*If* we introduce "yet" another attribute, then I think it should be worth considering adding the simple "@infered" or "@everything" wildcard or something.

Having a function whose attributes takes more room than the signature proper is pretty bad :/

Kind of not *directly* related to @nogc, but this DIP adds relevance to the "issue".

I mean, if we want this to actually be useful in Phobos (or other), it will require *massive* tagging all over the place.
April 15, 2014
On 4/15/2014 12:57 PM, monarch_dodra wrote:
> I mean, if we want this to actually be useful in Phobos (or other), it will
> require *massive* tagging all over the place.

I don't see that we have much choice about it.

Note that an entire file can be marked with just:

   @nogc:
April 15, 2014
On Tue, Apr 15, 2014 at 07:57:58PM +0000, monarch_dodra via Digitalmars-d wrote: [...]
> I have an issue related to adding an extra attribute: Attributes of non-template functions. Currently, you have to mark most functions as already pure, nothrow and @safe. If we are adding another attribute. Code will start looking alike this:
> 
> int someTrivialFunction(int i) @safe pure nothrow @nogc;
> 
> *If* we introduce "yet" another attribute, then I think it should be worth considering adding the simple "@infered" or "@everything" wildcard or something.
> 
> Having a function whose attributes takes more room than the signature proper is pretty bad :/
> 
> Kind of not *directly* related to @nogc, but this DIP adds relevance to the "issue".
> 
> I mean, if we want this to actually be useful in Phobos (or other), it will require *massive* tagging all over the place.

Is automatic inference of @nogc anywhere within our reach right now? That would save us a lot of grunt work marking up template functions in Phobos (and user code), not to mention the case of template functions with alias parameters, for which manual marking of @nogc may not even be possible.

But yeah, for non-template functions, some way of triggering attribute inference would be very helpful. What about @auto?


T

-- 
Why are you blatanly misspelling "blatant"? -- Branden Robinson
April 15, 2014
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.


April 15, 2014
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.