[zamberzand]

In my opinion, the current documentation on the autofree engine [0] constitutes a false claim about language capabilities:

> Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.

> The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object.

[0]: https://github.com/vlang/v/blob/master/doc/docs.md#memory-ma...

So, I am not entirely sure the best way to quantify whether this is true. However, I thought a fun test would be recreating "my first memory leak" -- the first memory leak I can remember fixing in code that I wrote. Specifically, I was essentially leaking some bespoke heap-allocated iterators I had created (inside of an infinite game loop).

So here is my little test:

    struct Iter {
    mut:
        pointer int
    }

    fn main() {
        my_array := [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ]
        
        for true { // simulated game loop
            mut iter := &Iter { 0 }
            
            // heap allocated iterator
            for iter.pointer < my_array.len {
                print(my_array[iter.pointer])
                print(" ")
                iter.pointer += 1
            }
            println("")
        }
    }

I compiled this with -autofree -gc none, with V 0.3. Checking it with valgrind, it continuously leaks memory.

So, from what I can tell, this description of the autofree engine in the documentation does not accurately describe the existing functionality available in V.

I am curious where the 90%-100% figure comes from. It is such a specific number that it implies to me, as a reader, that it comes from an empirical measurement of an existing system. But, there is no link to where this measurement was taken. In my opinion, the documentation should include some details about how these figures were generated.

[amedvednikov]

No, it describes it absolutely accurately:

> until V's autofree engine is production ready.

[zamberzand]

So, to be clear, is the intended reading of the documentation as follows?

> Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.

> The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object.

> These points are both currently untrue, and should not be relied on in code.

I'm hoping I don't come off as flippant here. I just don't see any way to interpret these claims as an accurate description without adding that third bullet point.

[amedvednikov]

They are both true, and it clearly says it's not production ready yet, so there are bugs.

[zamberzand]

Okay, I really don't understand what you're saying here.

The claims are objectively false. The autofree engine objectively does not free 90%-100% of objects, it is objectively not true that "It just works."

If I understand you, you're saying that autofree doesn't work because of bugs in the compiler. But, the fact that the claims are false as a result of bugs in the compiler does not somehow make those claims true.

[Tozen]

Autofree exists and does work (https://youtu.be/gmB8ea8uLsM), however, it doesn't work where a user can have a complete lack of understanding about memory management like various GCs do or have never used it before. Autofree, as it is, also requires looking at examples of usage in various programs.

The website and documentation does explain the situation, for those that cared to actually read them. "Right now allocations are handled by a minimal and well performing GC until V's autofree engine is production ready." This should be enough to understand that autofree is WIP and not enabled by default (which is referred to in the documentation).

The other issue, is that people who have never used V or autofree (not even talking outright detractors), might interject or repeat uninformed opinions about the situation. Where those that have more thoroughly experimented with autofree and have used V or are in the V community, would likely understand the situation and history of it (have read other things about it on V's GitHub or asked about it on discord).

[zamberzand]

I understand that autofree is WIP. I read that part of the docs, and I have watched the demo.

But I don't really understand what the intended reading of the documentation is.

If I were to completely take these two paragraphs out of context, they are factually untrue:

> Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.

> The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object.

So, what does this mean? Well, nothing, necessarily. If the context clarifies that these points are all untrue, then, the documentation could be considered perfectly accurate as far as I'm concerned.

However, when I asked if the intended reading of the documentation was that these points are untrue, the answer was--no, these points are all actually true.

I don't understand that position. These claims are straightforwardly untrue.

To me, your response is reinforcing my original proposed reading. That is--to me, your response indicates that I should read these claims as being false, and that the documentation is acknowledging them as false.

Now to me, that is a perfectly good response to my original comment. If this part of the documentation is not intended to be read as a statement of fact, that makes perfect sense to me, even though I do think it could be communicated better.

As it stands, though, I'm not really sure what I'm meant to get from this[0] comment.

[0] https://news.ycombinator.com/item?id=31955809