DIP60: @nogc attribute

[Manu via Digitalmars-d]

On 16 April 2014 19:03, JN via Digitalmars-d <digitalmars-d at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140416/0d7502a2/attachment.html>