mut p &Point should be allowed and mut p Point should be forbidden due to the increase in implicitness

[i582]

Describe the feature

Current behavior:

pub struct Point {
	x int
	y int
}

pub fn (mut p &Point) x() int {
//      ^^^^^^^^^^^^ error: use `(mut f Foo)` or `(f &Foo)` instead of `(mut f &Foo)`
	return p.x
}

I'm encouraged to use mut f Foo so that the fact that the receiver will actually be passed as a pointer will be lost and made implicit.

Since the language positions itself as simple, there should be less implicit things in it.

Use Case

See previous part.

Proposed Solution

The compiler should give an error for the following definition:

pub fn (mut p Point) x() int {
//           ^ no &
//           error: you must declare type as &Point for mutable receiver (mut p &Point)
	return p.x
}

This way the compiler checks that the code explicitly describes the fact that the value will be passed by pointer. This will reduce the implicitness in the language.

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

Version used

V 0.3.2 89aa695.865c0ea

Environment details (OS name and version, etc.)

OS: macos, macOS, 13.0.1, 22A400
Processor: 10 cpus, 64bit, little endian, Apple M1 Pro
CC version: Apple clang version 14.0.0 (clang-1400.0.29.202)

getwd: /Users/petrmakhnev/vlang-foundation/specification
vmodules: /Users/petrmakhnev/.vmodules
vroot: /Users/petrmakhnev/v
vexe: /Users/petrmakhnev/v/v
vexe mtime: 2023-01-22 21:48:01
is vroot writable: true
is vmodules writable: true
V full version: V 0.3.2 89aa695.865c0ea

Git version: git version 2.37.1 (Apple Git-137.1)
Git vroot status: weekly.2022.50-266-g865c0ea8-dirty
.git/config present: true
thirdparty/tcc status: thirdparty-macos-arm64 173c526e

[spytheman]

I agree 💯 with the proposed change.

What worries me is the This feature might incur a breaking change .

Do you have a plan for how to not break existing code, or break it minimally during the transition to the more explicit declarations?

[i582]

@spytheman

Steps:

1. Give time, for example, 3 months
2. At this time, vfmt will automatically fix it
   mut t Type -> mut t &Type
3. Allow and enable mut t &Type in the compiler
   These forms describe the same behavior, so what we do in the compiler is that these two forms compile into the same C code.
4. Add warning for mut t Type
5. Waiting for 3 months
6. Add a hard error for mut t Type

[spytheman]

Looks good to me.

[larpon]

I 100% support this also. Very welcome change

[medvednikov]

I used to be against this, but now I support it.

[JalonSolov]

Yeah, I've always been against it. Compilers should make things easier, instead of propagating the same silliness as always.

V should be able to figure out when the & is needed so that I don't have to waste cognitive effort on the decision.

However, most programmers continue to try to force V to be like C, so they use (or don't use) the & incorrectly, and we wind up where we are. 🤷‍♂️

[medvednikov]

@JalonSolov you do make a good point. That was my reasoning as well when I implemented this feature.

I think it would work well if it was like Python, where value/reference thing is completely hidden. But V does have &Foo/Foo, and it gets confusing here, where mut acts like &. This change just makes things more consistent.

[JalonSolov]

I'd rather disallow &Foo/Foo. :-)

[medvednikov]

Yeah I know :)

perhaps we can make a slower and simpler version of V (or a flag), where there's no &Foo :)

so that it works like Python and is used in high level apps where performance is not important

[medvednikov]

When I started V I wanted to make a language of the future, where caring about pointers/memory is not necessary. That's why I introduced this feature and all the automatic Foo/&Foo conversions.

V ended up being used in lots of low level/high perf environments, and this caused problems. Perhaps having two different versions for low/high level code is a viable option.