[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

[Tozen]

When a person new to V reads the documentation (which they should be doing), they would also see the following.

"Note 2: Autofree is still WIP. Until it stabilises and becomes the default, please avoid using it. Right now allocations are handled by a minimal and well performing GC until V's autofree engine is production ready."

So, autofree (as a WIP) is not at this point working as intended, which is described by, "The developer doesn't need to change anything in their code. "It just works"..." I don't take this as any attempt to mislead or deceive, like you seem to be doing. The documentation is even telling people to avoid using autofree, as it's WIP.

Yes, there is a difference between how autofree is suppose to work versus how it is presently working. Yes of course, I can totally see how people get very excited about autofree, and want it 100% working or want its development accelerated. But, it should be obvious that at this point, when a person is using it, they are experimenting. When a person takes it upon themselves to enable autofree, in an alpha status language, they shouldn't be surprised there are issues.

Then bringing it back to what I had typed about earlier, using autofree at this point, requires that the person understands something about memory management and looks at examples of its usage. Particularly when a person is going to enable it, against the recommendation of the documentation.

[zamberzand]

It seems we are essentially in agreement on how the documentation is meant to be read, which is that the points it makes about autofree are not meant to be statements of fact.

[Tozen]

Not exactly, because what I'm saying is that the V website and documentation is explaining what autofree does, describing what autofree is, and how it works.

It appears you are implying that if autofree doesn't work perfectly as it is described, then that indicates a false claim or deception.

The counter to that (and what I'm saying) is that the website and documentation states that autofree is WIP and even recommends not to use it, and tells users that at this time GC is used instead. There is no deception, they are being clear. So if the user goes against the recommendation of the documentation, they should not be surprised that WIP autofree in alpha status V, is not working perfectly.

Furthermore, autofree does exist. We are not talking about a lie or false claim, where something is not in existence. Autofree does function, so here too, we are not talking about something that does not work at all. We are now talking about to the degree it is working or how well it works. Which on that point, the website and documentation both indicate WIP, so a user should not yet expect it to fully function.

I further elaborated that if you experiment with it, you may get autofree to work well. But, that can depend on: the program, can require experience using V, some memory management knowledge, and/or going through examples of V programs that use it. The expectation (and what those in the V community are aware of) is that as V goes to higher versions on its way to beta status, we will see better performing versions of autofree that requires less to no needed user knowledge about details.