On Wednesday, 10 July 2013 at 09:06:10 UTC, Paulo Pinto wrote:
On Wednesday, 10 July 2013 at 08:00:55 UTC, Manu wrote:
On 10 July 2013 17:53, Dicebot <pub...@dicebot.lv> wrote:
On Wednesday, 10 July 2013 at 07:50:17 UTC, JS wrote:
...
I am pretty sure stuff like @nogc (or probably @noheap. or
both) will have
no problems in being accepted into the mainstream once
properly
implemented. It is mostly a matter of volunteer wanting to
get dirty with
the compiler.
I'd push for an ARC implementation. I've become convinced
that's what I
actually want, and that GC will never completely satisfy my
requirements.
Additionally, while I can see some value in @nogc, I'm not
actually sold on
that personally... it feels explicit attribution is a
backwards way of
going about it. ie, most functions may actually be @nogc, but
only the ones
that are explicitly attributed will enjoy that recognition...
seems kinda
backwards.
That is the approach taken by other languages with untraced
pointers.
Actually I prefer to have GC by default with something like
@nogc where it really makes a difference.
Unless D wants to cater for the micro-optimizations folks
before anything else, that is so common in the C and C++
communities.
It's not about any micro-optimizations. Many real time
applications simply can't use D because of it's stop the world
GC(at least not without a great amount of work or severe
limitations).
By having a @nogc attribute people can start marking their code,
the sooner the better(else, at some point, it because useless
because there is too much old code to mark). @nogc respects
function composition... so if two functions do not rely on the gc
then if one calls the other it will not break anything.
So, as libraries are updated more and more functions are
available to those that can't use gc code, making D more useful
for real time applications. If custom allocation methods ever
come about then the @nogc may be obsolete are extremely useful
depending on how the alternate memory models are implemented.
Code that only use stack allocation or static heap allocation
have no business being lumped in with code that is gc dependent.
