Is it necessary for V language to consider adding ownership mechanisms in the future?

[Avey777]

MoJo Confirm Use Ownership：https://docs.modular.com/mojo/manual/values/

Ownership is a great invention. I think V language should not abandon it completely. Using some of its best parts will be better for the future development of V language.

And ownership should be the same as manually managed memory, compatible with autofree and gc compilation methods

As officially described, V's official package is provided through autofree to support compilation methods such as gc and autofree. However, it is also said that the performance of the autofree method provided by V is not necessarily better than that of gc. Not only is it laborious to manage memory manually, it can also easily lead to memory leaks. As time goes by and the complexity of packages grows, how to better maintain these packages becomes a problem. All limited support ownership will give V a better future

[medvednikov]

I think it's ok, but only strictly as an option. For those few % of cases where it's really wanted/needed.

Similar to manual memory management option, which we support.

[Avey777]

I look forward to the day when V can support memory management through ownership.

V language should not place too much emphasis on compilation speed. It should provide an option to deeply optimize code running speed during compilation, so as to cater to embedded systems that have extreme requirements for code running speed. Of course, autofree without GC is also necessary for embedded systems

[JalonSolov]

While supporting embedded systems is a worthwhile goal, it is not the main driving force behind V (or any other general purpose language). So while it would be fine if such support was added as an option, it should not be the main focus.

[Wajinn]

My interpretation of the context about this, is the language and it's syntax stays convenient for the average/most users, and then they can choose other methods of memory management (beyond the default) based on their need. V's performance with the default GC is very good (in addition to providing memory safety), which will be fine for most users. For those advanced users and certain situations, they have autofree and arena allocation. Possibly something else in the future as well. Thus, V's stated focus on providing flexible/optional memory management.

Unlike other languages, users are not hit with or burdened with unnecessary difficulties and problems. If the task specifically requires a different kind of memory management or if an advanced user wants to handle memory management differently, then V can provide other options which are compatible with its core design principles and goals.

[Avey777]

This is the answer I'm looking forward to