On Sunday, 28 May 2017 at 17:34:30 UTC, Nerve wrote:
Thanks to Walter Bright's recent comments at Dconf about memory
safety, and my own lamentations about the continued use of C in
all contexts where memory safety is crucial by overconfident
programmers who believe they can do no wrong, I've decided to
propose a baked-in RAII implementation for D.I would like to
submit a DIP, but first I'd like to run it by the forum
community and see what improvements need to be made, possibly
due to my own naivety on the subject.
D already has baked-in RAII; acquire the resource in a
constructor, release it in a destructor. I assume you are
referring to object lifetime management?
Phobos already has it, and there's the automem library by Atila
Neves. However, I think the perception shift gained by baking
in these features will benefit D enormously.
Phobos and automem provide mechanisms for object lifetime
management and some objects in Phobos use RAII (such as
std.stdio.File).
D users can run around all day trying to convince people that
different library implementations of RAII exist so one need not
use the GC, but the only thing that is going to convince the
programming world at large is a giant announcement on Reddit,
HackerNews, and other places that "Hey, D has RAII now!" This
will also drive many new eyes to the language that never would
have looked otherwise.
To be clear:
- RAII is binding a resource's lifetime to an object's lifetime,
so that a resource leak can only occur when an object leak occurs
- D offers memory and object lifetime management via the GC in
druntime
- Phobos offers an advanced memory management framework via
std.experimental.allocator
- Phobos offers object lifetime management via
+ std.typecons.RefCounted: Reference counting
+ std.typecons.Unique: Single owner
However, since these are older than std.experimental.allocator,
they do not use the latter for managing the memory of their
objects
- automem offers object lifetime management with the same
RefCounted / Unique model as std.typecons, but with its memory
backed by the std.experimental.allocator framework
With regards to your popularity argument: IMHO the only people we
should concern ourselves with are those that evaluate which are
the right tools for their current task as objectively as feasible
given their respective circumstances, not those that are swayed
by whatever is the current hype on social site XYZ. But that's
just me.
There are also the obvious syntactical benefits. Referencing an
RAII object and its members would be literally no different
than referencing a GC heap object. No need to fiddle with
library constructs to extract one's reference.
This is what `alias this` exists for.
[...]
@nogc void main()
{
auto refCountedObject = refcounted Object();
} // References go to 0, object is destroyed
To be honest I think this is no different to read than
---
@nogc void main()
{
auto refCountedObject = RefCounted!Object();
} // References go to 0, object is destroyed
---
which we already have for free thanks to templates.
[...]
I may be missing some things, but I've left out some exhaustive
details since I'm sure many of you are already experienced in
the subject and aren't looking for complete documentation in a
proposal like this.
Feel free to level criticism, and let me know if I should
submit a DIP.
AFAICT all of your examples look (and work) pretty much the same
if you used templates. Only differences would be that each
`unique X(...)` becomes `Unique!X(...)`, analogous for refcounted.
All in all, I see little to no benefit to what you propose, while
requiring significant work on the language spec.
