On Tue, 15 Apr 2014 16:48:42 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

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

Oops! Needed to refresh my browser, thanks.

-Steve

On Tue, 15 Apr 2014 16:06:26 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

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

Then let's please have @gc.

-Steve

On Tuesday, 15 April 2014 at 20:56:24 UTC, Steven Schveighoffer wrote:
> On Tue, 15 Apr 2014 16:06:26 -0400, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> 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:
>
> Then let's please have @gc.
>
> -Steve

Yes, please. Too few of the attributes have inverse attributes.

Being able to stick your defaults up at the top of your module and then overriding them only when needed would be very nice and make the code a lot more tidy.

Also, it'd be nice if you could optionally stick a @ before some of the attributes to make everything consistent looking.

@pure @nothrow @nogc: /* Mmm */

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.

On Tue, Apr 15, 2014 at 01:40:07PM -0700, Walter Bright via Digitalmars-d wrote:
> 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

I'm not sure I like the idea of overloading "auto" to mean *both* "automatically infer return type" and "automatically infer attributes".

What about @auto or @default for attribute inference, and leave return type inference as-is?


T

-- 
Too many people have open minds but closed eyes.

On Tuesday, 15 April 2014 at 20:40:05 UTC, Walter Bright wrote:
>> I had a PR for that, but nobody liked it.
>
> https://github.com/D-Programming-Language/dmd/pull/1877

If I correctly understand the reservations raised against this PR, the people objecting might have agreed to attribute inference for *private* functions, would this be worth pursuing?

On Tuesday, 15 April 2014 at 21:41:37 UTC, Brad Anderson wrote:
> Yes, please. Too few of the attributes have inverse attributes.
>
> Being able to stick your defaults up at the top of your module and then overriding them only when needed would be very nice and make the code a lot more tidy.

Then you need a compiler option that will prevent @gc, otherwise you risk libraries pulling in @gc code as quick fixes without library users that want @nogc noticing the deficiency.

Ola.

On 16 April 2014 01:45, via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Then you need a compiler option that will prevent @gc, otherwise you risk libraries pulling in @gc code as quick fixes without library users that want @nogc noticing the deficiency.

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.

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

First of all, I have the following suggestions for the DIP:
*  Articulate a more thorough motivation for this feature other than to give users what they want.
*  Summarize previous discussions and provide links to them.
*  Provide some justification for the final decision, even if it's subjective.

I don't believe users hesitant to use D will suddenly come to D now that there is a @nogc attribute.  I also don't believe they want to avoid the GC, even if they say they do.  I believe what they really want is to have an alternative to the GC.

I suggest the following instead:
1.  Provide the necessary druntime hooks to enable developers to create a variety of memory management implementations.
2.  Given these hooks and ideas that have been discussed in the community and presented at DConf, improve D's default GC.
3.  Implement a variety of alternative memory managers (official and unofficial) that can be compiled and/or linked into druntime and/or the program.

Alternative memory managers could include the following:
* Default D2 mark-and-sweep GC for backward compatibility
* Concurrent, precise or otherwise improved D2 mark-and-sweep GC
* Reference counting with mark-and-sweep fallback
* Automatic malloc, manual free
* Manual malloc, manual free
* {Insert your favorite here}

Users can use 'if version(x)' if they wish to support more than one memory management scheme, and their choice forces them to change their idioms.

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.

Bottom line:
IMO, memory management is an implementation detail of the problem domain, not the language, and it's implementation should be delegated to a library or to the programmer.

Mike

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