Built-in RAII in D

[Moritz Maxeiner via Digitalmars-d]

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.