On Wednesday, 10 July 2013 at 11:38:35 UTC, JS wrote:
On Wednesday, 10 July 2013 at 10:56:48 UTC, Paulo Pinto wrote:
On Wednesday, 10 July 2013 at 10:40:10 UTC, JS wrote:
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 <[email protected]> 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.
I do agree D needs something like @nogc, something like
untraced pointer as I mentioned.
What I am speaking against is making GC a opt-in instead of
the default allocation mode.
I agree but it's not going to happen ;/
In such case it looks more as a workaround instead of fixing
the real problem, which is having a better GC.
Note that by GC, I also mean some form of reference counting
with compiler support to minimize increment/decrement
operations.
I don't know if that is a solid statement. ARC is pretty
different from AGC.
Reference counting is pretty much seen as a primitive form of
garbage collection in the CS literature.
In some books it is usually the first chapter, hence the way I
phrased my comment.
--
Paulo
