[edflsafoiewq]

Not sure what you mean. The elements of an ArrayList(ArrayList(i32)) are ArrayList(i32)s.

To answer my question, no, they're not deinited. All deinit does is call self.allocator.free on the slice of elements, and for many allocators that's a nop. In fact none of ArrayLists methods take any kind of ownership of its elements. If you shrink an ArrayList(ArrayList(i32)) by one you leak the last ArrayList(i32). None of the methods call destructors on the elements because there is no generic notion of a destructor, only particular ad-hoc ones like deinit methods. ArrayList appears to solve the problem I mentioned above about generics not knowing if a generic type needs to have a destructor called by only supporting types that don't.

In C++, you'd write the function that clears a vector something like

    void clear() {
        for (auto p = ptr; p != ptr + len; ++p) {
            p->~T();
        }
        len = 0;
    }

For a vector<vector<int>> the syntax p->~T() calls the destructor on a vector<int> element. While for an vector<int> the syntax p->~T() is a pseudo-destructor call, ie. it does nothing. This makes the same generic code work when the elements of a vector need to have a destructor called and when they don't.

[AnIdiotOnTheNet]

> Not sure what you mean. The elements of an ArrayList(ArrayList(i32)) are ArrayList(i32)s.

I believe what he was wasking was "given an ArrayList(i32), how would you expect it to call deinit on the member i32s?". The answer, of course, is that you don't, which is also true of ArrayList(ArrayList(i32)). ArrayList absolutely supports heap-allocated types, you just have to free them yourself before calling deinit() on the ArrayList itself.

[edflsafoiewq]

Which only brings us again (putting aside what virtue recommends that design over having destructors) to the same original question. If I have an ArrayList(T) for a generic type T, how do I know if the elements need to be freed before I deinit and how do I do that if they do?

[AnIdiotOnTheNet]

I'm having trouble imagining a scenario where you'd have code that was so generic it could take an ArrayList of any arbitrary type and would also be responsible for its destruction.

But if you did, you could use `@TypeInfo` to inspect the inner type for a function named `deinit`, or some other criteria that made sense for this determination.

[edflsafoiewq]

Any generic data type with a private ArrayList(T) member is an example. Unless you also expect callers to manually run destructors for elements of a type's private members, and their private members, etc. And it's not just about destroying the ArrayList entirely. Any function which just removes elements from an ArrayList needs to know how to destroy elements or else pass the buck for half its purpose to the caller. When I call shrink on an ArrayList(ArrayList(i32)) I'm supposed to preloop over the shrunken-over elements and call deinit on them before I call shrink? When I call the function that removes elements satisfying a predicate I'm supposed to preloop over the elements and call deinit on the ones I'm about to remove? Obviously not.

I already mentioned that hack. All you're doing there is introducing the ad-hoc notion of a destructors as a method named deinit. Again, in order for that to work in generic code that convention needs to be blessed by the language.

[AnIdiotOnTheNet]

> Again, in order for that to work in generic code that convention needs to be blessed by the language.

Technically it only needs to be blessed by the standard library in this case.