Standardise References And Pointers

[l1mey112]

Standardise the current functionality with pointers and references, and remove ambiguities. Created after a lengthy talk with @spytheman and @medvednikov in #compiler-and-vlib-dev.

[Casper64]

Hey, there is one thing that confuses me a bit: why in the following example is C.external defined with a mut parameter, but called without the mut keyword?

// src
fn C.external(mut &AA)

fn test0(mut v AA) {
	C.external(&v)
}

To me this reads that C.external will modify its parameter and that that parameter is a pointer. But if I didn’t see the definition of C.external and only saw the code of test0 then I would assume that C.external does not modify v.

Ofcourse because it is a C function it could do anything with the pointer, but for V readability I would think it’s nice to have to use C.external(mut &v), if I understand your proposal correctly, to indicate that this function indeed modifies v. That is if you define a parameter in a C function as mut.

[danieldaeschle]

Hey, there is one thing that confuses me a bit: why in the following example is C.external defined with a mut parameter, but called without the mut keyword?

// src
fn C.external(mut &AA)

fn test0(mut v AA) {
	C.external(&v)
}

To me this reads that C.external will modify its parameter and that that parameter is a pointer. But if I didn’t see the definition of C.external and only saw the code of test0 then I would assume that C.external does not modify v.

Ofcourse because it is a C function it could do anything with the pointer, but for V readability I would think it’s nice to have to use C.external(mut &v), if I understand your proposal correctly, to indicate that this function indeed modifies v. That is if you define a parameter in a C function as mut.

Looks like just missed mut.

[l1mey112]

Looks like just missed mut.

I did, will update the RFC. I don't believe V supports mut &v anyway yet.