Ownership+borrowing, can achieve memory security without lifecycle labeling

[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.

[hellolio]

I am not optimistic about the future of ownership mechanisms in V. I still believe that autofree + GC is the optimal choice. Most users handle memory with autofree (80%) + GC (20%), while advanced users handle memory with autofree (80%) + manual management (20%).
It's not that I dislike ownership mechanisms, but I believe that in a language, you should either use ownership or manual memory management. V has already made its choice, and the ownership mechanism is not suitable for V
You can't have both at the same time, as it would make the language bloated.

[Avey777]

I am not optimistic about the future of ownership mechanisms in V. I still believe that autofree + GC is the optimal choice. Most users handle memory with autofree (80%) + GC (20%), while advanced users handle memory with autofree (80%) + manual management (20%).
It's not that I dislike ownership mechanisms, but I believe that in a language, you should either use ownership or manual memory management. V has already made its choice, and the ownership mechanism is not suitable for V
You can't have both at the same time, as it would make the language bloated.

V can introduce a limited entitlement mechanism that does not require the full functionality of Rust. This would be very useful for performance jitter-sensitive scenarios.

[Wajinn]

V can introduce a limited entitlement mechanism that does not require the full functionality of Rust. This would be very useful for performance jitter-sensitive scenarios.

If I'm reading correctly, I think you mean some type of simplified system of ownership and move semantics, but without being as heavy or overbearing as Rust's borrow checker. More user friendly and simpler variations are likely to come, because of more available knowledge and awareness.

It seems V would be a good candidate to implement such a mechanism, because of how the language was influenced and is already constructed. It looks like a matter of constructing rules to be adhered to on how to do the borrowing, that matches the existing language. V's memory management section in the documentation, seems to be already hinting at what such V rules could look like.

The goal for some could be to see to what extent GC usage can be reduced, like the concept of autofree, to 20% or less. So in the case of whatever is used, autofree or some new mechanism, the goal might be GC usage reduction and detailing use cases of when there is a benefit over full GC. With the added option to use the GC or not, as a kind of fail-safe. Along those lines, it could be explored if the GC can be made more efficient, by various tweaks and tailoring it more to V.

V should still provide options. Meaning, users could choose to continue using the GC, to not be bothered by the compiler about memory management. Where if the GC is turned off, they might see compiler warnings or errors for violating rules. Likely, done by flag, where all of it can be optionally turned off or on. But now a more progressive system on memory management would be introduced. From full automatic, semi-automatic variations, and then towards fully manual. This would be something to look at in more detail, as we get closer to version 0.6 of V, per discussion comment. Regardless, GC should stay the default, for greater convenience.

[Avey777]

In fact, in some cases, we are forbidden to use gc! This simpler ownership provides us with memory security while also allowing us to avoid managing memory manually as much as possible.

Memory management at compile time is a trend.

[medvednikov]

@Wajinn good write-up as always. I agree with you 100%. That's how it will be :)

[Avey777]

Implement a compile-time enforced ownership/borrowing system with these rules:

Ownership Rules

Values have single owners

1.Assignment transfers ownership (move semantics)

s1 := 'text'
s2 := s1  // Ownership moved
// s1 now inaccessible

2.Borrowing Syntax

Immutable borrowing (&T):

s := 'hello'
r := &s  // Read-only borrow
println(*r)

Mutable borrowing (&mut T):

mut s := 'world'
mr := &mut s
*mr = 'updated'

3.Compiler Enforcement

Prevent use-after-move

Enforce borrowing rules:

Only one mutable borrow OR multiple immutable borrows

No borrowing after ownership transfer

Automatic lifetime validation

Key Benefits
1.Memory Safety Guarantees

No dangling pointers

No data races

No null dereferences

2.Zero Runtime Overhead

All checks at compile-time

3.Minimal Syntax

Only 3 new operators: &, &mut, * (dereference)

4.Backward Compatibility

Opt-in via compiler flag initially

Critical Checks

// Should COMPILE
mut data := [1,2,3]
{
    r := &mut data
    *r[0] = 5
}
r2 := &data

// Should FAIL
x := 'a'
y := &x
z := x  // Error: x borrowed while moving

// Should FAIL
mut arr := [1,2]
r1 := &arr
r2 := &mut arr  // Conflict with r1

Implementation Requirements
1.Ownership tracking in compiler

2.Borrow checker with scope analysis

3.Move semantics for assignments/parameters

4.Lifetime inference engine

[Avey777]

For embedded systems that require performance, security, and low memory usage, v is more suitable for embedded development if it can support a simplified version of compile-time memory management.
For the future world, AI will promote the intelligent development of the world, and the market of embedded development will greatly increase.
So v would be more advantageous if it could support a simplified version of compile-time memory management.