On Wednesday, 16 April 2014 at 08:46:56 UTC, Ola Fosheim Grøstad wrote:
> 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.

Btw, I think you should add @noalloc also which prevents both new and malloc. It would be useful for real time callbacks, interrupt handlers etc.

On Wednesday, 16 April 2014 at 01:57:29 UTC, Mike wrote:
> 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'd have to agree. I doubt @nogc will change anything, people will just start complaining about limitations of @nogc (no array concat, having to use own libraries which may be incompatible with phobos). The complaints mostly come from the fact that D wants to offer a choice, in other languages people just accept what they have. You don't see C# developers complaining much about having to use GC, or C++ programmers all over the world asking for GC. Well, most of the new games (Unity3D) are done in C# nowadays and people live with it even though game development is one of the biggest C++ loving and GC hating crowd there is.

Another issue is the quality of D garbage collector, but adding alternative memory management ways doesn't help, fragmenting the codebase.

On Wednesday, 16 April 2014 at 09:03:22 UTC, JN wrote:
> I'd have to agree. I doubt @nogc will change anything, people will just start complaining about limitations of @nogc (no array concat, having to use own libraries which may be incompatible with phobos). The complaints mostly come from the fact that D wants to offer a choice, in other languages people just accept what they have.

The complaints mostly come from the fact that D claims to be a system programming language capable of competing with C/C++.

Stuff like @nogc, @noalloc, @nosyscalls etc will make system level programming with reuse of code more manageable.

I find it troublesome that D is compared to Java, C# and Go, because those languages are not system level programming languages.

JN:

> I doubt @nogc will change anything, people will just start complaining about limitations of @nogc

Having a way to say "this piece of program doesn't cause heap activity" is quite useful for certain piece of code. It makes a difference in both performance and safety.
But not being able to call core.stdc.stdlib.alloca in a "@nogc pure" function sub-three is not good.

Bye,
bearophile

On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
> http://wiki.dlang.org/DIP60

Walter, the DIP has a funny creation date.

On Wednesday, 16 April 2014 at 09:17:48 UTC, Ola Fosheim Grøstad
wrote:
> On Wednesday, 16 April 2014 at 09:03:22 UTC, JN wrote:
>> I'd have to agree. I doubt @nogc will change anything, people will just start complaining about limitations of @nogc (no array concat, having to use own libraries which may be incompatible with phobos). The complaints mostly come from the fact that D wants to offer a choice, in other languages people just accept what they have.
>
> The complaints mostly come from the fact that D claims to be a system programming language capable of competing with C/C++.
>
> Stuff like @nogc, @noalloc, @nosyscalls etc will make system level programming with reuse of code more manageable.
>
> I find it troublesome that D is compared to Java, C# and Go, because those languages are not system level programming languages.

A system level programming language is a language that can be
used to write a full stack OS with it, excluding the required
Assembly parts.

There are a few examples of research OS written in the said
languages.

--
Paulo

On 16 April 2014 19:03, JN via Digitalmars-d <digitalmars-d@puremagic.com>wrote:

> On Wednesday, 16 April 2014 at 01:57:29 UTC, Mike wrote:
>
>> 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'd have to agree. I doubt @nogc will change anything, people will just start complaining about limitations of @nogc (no array concat, having to use own libraries which may be incompatible with phobos). The complaints mostly come from the fact that D wants to offer a choice, in other languages people just accept what they have. You don't see C# developers complaining much about having to use GC, or C++ programmers all over the world asking for GC. Well, most of the new games (Unity3D) are done in C# nowadays and people live with it even though game development is one of the biggest C++ loving and GC hating crowd there is.
>
> Another issue is the quality of D garbage collector, but adding alternative memory management ways doesn't help, fragmenting the codebase.
>

I don't really have an opinion on @nogc, but I feel like I'm one of the
people that definitely should.
I agree with these comments somewhat though.

I have as big a GC-phobia as anyone, but I have never said the proper
strategy is to get rid of it, and I'm not sure how helpful @nogc is.
I don't *mind* the idea of a @nogc attribute; I do like the idea that I may
have confidence some call tree doesn't invoke the GC, but I can't say I'm
wildly excited about this change. I'm not sure about the larger
implications for the language, or what the result of this will do to code
at large. I'm not yet sure how annoying I'll find typing it everywhere, and
whether that's a worthwhile tradeoff.
I have a short list of things I'm dying for in D for years, and this is not
on it. Nowhere near. (rvalue temp -> ref args pleeeease! Linear algebra in
D really sucks!!)

The thing is, this doesn't address the problem. I *want* to like the GC... I want a GC that is acceptable.

I am convinced that ARC would be acceptable, and I've never heard anyone
suggest any proposal/fantasy/imaginary GC implementation that would be
acceptable...
In complete absence of a path towards an acceptable GC implementation, I'd
prefer to see people that know what they're talking about explore how
refcounting could be used instead.
GC backed ARC sounds like it would acceptably automate the circular
reference catching that people fuss about, while still providing a workable
solution for embedded/realtime users; disable(/don't link) the backing GC,
make sure you mark weak references properly.

That would make this whole effort redundant because there would be no fear of call trees causing a surprise collect under that environment.

Most importantly, it maintains compatibility with phobos and all other libs. It doesn't force realtime/embedded users into their own little underground world where they have @nogc everywhere and totally different allocation API's than the rest of the D universe, producing endless problems interacting with libraries. These are antiquated problems we've suffered in C++ for decades that I _really_ don't want to see transfer into D.

I'd like to suggest experts either, imagine/invent/design a GC that is acceptable to the realtime/embedded crowd (seriously, can anyone even _imagine_ a feasible solution in D? I can't, but I'm not an expert by any measure), or take ARC seriously and work out how it can be implemented; what are the hurdles, are they surmountable? Is there room for an experimental fork?

On Wednesday, 16 April 2014 at 11:51:07 UTC, Manu via Digitalmars-d wrote:
> On 16 April 2014 19:03, JN via Digitalmars-d <digitalmars-d@puremagic.com>wrote:
>
>> On Wednesday, 16 April 2014 at 01:57:29 UTC, Mike wrote:
>>
>>> 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'd have to agree. I doubt @nogc will change anything, people will just
>> start complaining about limitations of @nogc (no array concat, having to
>> use own libraries which may be incompatible with phobos). The complaints
>> mostly come from the fact that D wants to offer a choice, in other
>> languages people just accept what they have. You don't see C# developers
>> complaining much about having to use GC, or C++ programmers all over the
>> world asking for GC. Well, most of the new games (Unity3D) are done in C#
>> nowadays and people live with it even though game development is one of the
>> biggest C++ loving and GC hating crowd there is.
>>
>> Another issue is the quality of D garbage collector, but adding
>> alternative memory management ways doesn't help, fragmenting the codebase.
>>
>
> I don't really have an opinion on @nogc, but I feel like I'm one of the
> people that definitely should.
> I agree with these comments somewhat though.
>
> I have as big a GC-phobia as anyone, but I have never said the proper
> strategy is to get rid of it, and I'm not sure how helpful @nogc is.
> I don't *mind* the idea of a @nogc attribute; I do like the idea that I may
> have confidence some call tree doesn't invoke the GC, but I can't say I'm
> wildly excited about this change. I'm not sure about the larger
> implications for the language, or what the result of this will do to code
> at large. I'm not yet sure how annoying I'll find typing it everywhere, and
> whether that's a worthwhile tradeoff.
> I have a short list of things I'm dying for in D for years, and this is not
> on it. Nowhere near. (rvalue temp -> ref args pleeeease! Linear algebra in
> D really sucks!!)
>
> The thing is, this doesn't address the problem. I *want* to like the GC...
> I want a GC that is acceptable.
>
> I am convinced that ARC would be acceptable, and I've never heard anyone
> suggest any proposal/fantasy/imaginary GC implementation that would be
> acceptable...
> In complete absence of a path towards an acceptable GC implementation, I'd
> prefer to see people that know what they're talking about explore how
> refcounting could be used instead.
> GC backed ARC sounds like it would acceptably automate the circular
> reference catching that people fuss about, while still providing a workable
> solution for embedded/realtime users; disable(/don't link) the backing GC,
> make sure you mark weak references properly.
>
> That would make this whole effort redundant because there would be no fear
> of call trees causing a surprise collect under that environment.
>
> Most importantly, it maintains compatibility with phobos and all other
> libs. It doesn't force realtime/embedded users into their own little
> underground world where they have @nogc everywhere and totally different
> allocation API's than the rest of the D universe, producing endless
> problems interacting with libraries. These are antiquated problems we've
> suffered in C++ for decades that I _really_ don't want to see transfer into
> D.
>
> I'd like to suggest experts either, imagine/invent/design a GC that is
> acceptable to the realtime/embedded crowd (seriously, can anyone even
> _imagine_ a feasible solution in D? I can't, but I'm not an expert by any
> measure), or take ARC seriously and work out how it can be implemented;
> what are the hurdles, are they surmountable? Is there room for an
> experimental fork?


Specially when C# is already blessed on the PS4, although not for AAA games of course.

http://tirania.org/blog/archive/2014/Apr-14.html

--
Paulo

On 4/16/14, 2:03 AM, JN wrote:
> On Wednesday, 16 April 2014 at 01:57:29 UTC, Mike wrote:
>> 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'd have to agree. I doubt @nogc will change anything, people will just
> start complaining about limitations of @nogc (no array concat, having to
> use own libraries which may be incompatible with phobos). The complaints
> mostly come from the fact that D wants to offer a choice, in other
> languages people just accept what they have. You don't see C# developers
> complaining much about having to use GC, or C++ programmers all over the
> world asking for GC. Well, most of the new games (Unity3D) are done in
> C# nowadays and people live with it even though game development is one
> of the biggest C++ loving and GC hating crowd there is.
>
> Another issue is the quality of D garbage collector, but adding
> alternative memory management ways doesn't help, fragmenting the codebase.

My perception is the opposite. Time will tell. -- Andrei

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

Good start.

However, what is still an open issue is that @nogc can be stopped by allocations in another thread. We need threads which are not affected by stop-the-world. As far as I know, creating threads via pthreads C API directly achieves that, but integration with @nogc could provide more type safety. Stuff for another DIP?