[bheadmaster]

> You pointed to an old version of the documentation

Yes, because that version of documentation specified a feature that was impossible, which is exactly what we're discussing.

> V never promised autofree without GC or RC

First of all, I never mentioned "autofree without RC". I am strictly speaking about "autofree without GC".

Second of all, V documentation has had the "autofree frees 90% of objects, RC frees everything else" segment, which clearly implies no GC. So the documentation has clearly specified that feature, which was an impossible feature.

Even the next paragraph says:

    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 yeah, V promised autofree without GC.

[amedvednikov]

And again, everything written is correct.

No heavy GC tracing everything or expensive RC for each object.

What's your issue with the wording?

[bheadmaster]

> What's your issue with the wording?

1) The first sentence clearly stated that:

    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.

Which explicitly implies that objects are exclusively freed only by autofree and reference counting.

2) Your emphasis of "everything" seems to imply a contrast to Python or Go method of memory deallocation:

    "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything

which would mean that Python, Go and Java trace everything, which isn't true. None of the three languages (Python, Go, or Java) use GC to trace everything - there are multiple optimizations (such as escape analysis and reference counting) that allow a certain percentage of objects to be freed by means other than tracing GC.

[amedvednikov]

> Which explicitly implies that objects are exclusively freed only by autofree and reference counting.

Yes, and what's wrong with that? That's how it works now too, except RC has been replaced by a tracing GC.

[Tozen]

V is not a finished product nor 1.0 yet. It's unproductive to act like things were carved in stone, from day 1. Programming languages go through development phases, where things do change and lead developers are allowed to make changes.

[bheadmaster]

I completely agree.

But gaslighting people and pretending that overly grandiose claims/promises haven't been made in the past leaves a bitter taste, and doesn't inspire trust in core developers. Instead, it makes me think that the core devs are incapable of admitting a mistake - which would make their language a hazard.

For example, what if V gets huge and a serious security bug gets discovered - how can I trust that the developers will properly communicate the existence of such a bug and not just keep quiet about it, consider how they aren't even willing to admit that V has made some impossible claims/promises in the past? If I discover a bug, will they also pretend that the bug doesn't exist, even when confronted with indisputable evidence, because it threatens to damage their reputation?

As long as that attitude doesn't change, I'm not touching V with a 10 foot pole.

[amedvednikov]

There's no pretending, see my reply to you above.

[bheadmaster]

You're still pretending that V has never made an impossible claim, which I have clearly demonstrated that it has.

See my numerous replies to you in this thread, where I have quoted the documentation, provided the archive.org link and explained why the claim is impossible.

Do you have any other argument except "nuh-uh, didn't happen, lol"?

[amedvednikov]

You still haven't listed any impossible claims, only something about autofree and GC copied from the website. What's impossible about that?