Thoughts from newcommer

[Stanislav Blinov via Digitalmars-d]

On Monday, 17 April 2017 at 21:20:42 UTC, Jerry wrote:

> So what happens when the resource outlives the object's 
> lifetime.

Then RAII rule is violated.

> That's exactly what is happening when you are using the garbage 
> collector.

Correction, that is what *may* happen in some cases when you are 
using GC.

> That's exactly the case with the containers in phobos. So 
> calling them RAII container is just incorrect.

I never said they were. You see, you were stating that in order 
for them to become such, they should be @nogc, which is simply 
not true. @nogc disallows GC calls, nothing more. You *can* have 
a RAII type that calls into GC. In fact, you can wrap a class 
reference into a struct that calls new in constructor and destroy 
in desctructor, and have a scoped lifetime for class instances 
that way. But such a struct's constructor and destructor cannot 
be @nogc.

>>> Not to mention for some reason Array's internal 
>>> implementation is ref counted. If you want ref counted arrays 
>>> you should do RefCounted!(Array!T). Std.containers is just a 
>>> giant mess.
>>
>> The "some reason" is mutable slices.
>
> Not really, slices aren't included in the ref counting.

Yes, they are.

> So if the array object is detroyed, the slices are no longer 
> valid.

The underlying storage is destroyed once the last reference dies, 
not when Array's destructor is called.

> You have to deal with the same issue, with or without ref 
> counting. You manually have to ensure the array outlives the 
> slice...

No.

> and that the slices aren't invalidated by an operation like 
> resize.

That is true.

My argument was, from the start, that assessing the *language* 
RAII capability has nothing to do with *library* containers or 
the (lack of) use of @nogc attribute.