Clarification questions about pointers and struct immutability

[CanyonTurtle]

Firstly, I think that v looks very promising and succinct!

I have 2 clarification questions, one about pointers and the other about struct immutability.

1. The documentation has one example with pointers. This example shows that pointers get declared and initialized along with the struct they are pointing to. Is this the only way to make pointers, or is it possible to do declare and initialize pointers so that they refer to pre-existing structs? This is the section I am referring to in the docs, from the Structs subsection:

// & prefix returns a pointer to the struct value.  
	// It's allocated on the heap and automatically cleaned up
	// by V at the end of the function, since it doesn't escape.  
	pointer := &Point{10,10} 
	println(pointer.x, pointer.y) // Pointers have the same syntax for accessing fields  

For instance, is it possible to do the following?

	p := Point{10,10}
	pointer := &p
	println(pointer.x, pointer.y)

2. Why is it that a struct that is declared and initialized without the mut keyword can be passed into a receiver which will modify the fields of that struct? For instance, the user struct here isn't declared with mut, and yet its fields get modified by the register() method. So then, how would one guarantee that the fields of user do not get modified by any methods? In other words, how is it possible for structs to be "immutable by default:?" Or, am I misunderstanding something about "deep immutability" versus "shallow immutability" here?

struct User {
	is_registered bool 
} 

fn (u mut User) register() {
	u.is_registered = true 
} 

fn main() {
	user := User{} 
	println(user.is_registered) // ==> "false"  
	user.register() 
	// TODO: Maybe force marking methods that modify the receiver with `!`
	// user.register()!  
	println(user.is_registered) // ==> "true"  
} 

Thanks for reading!

[medvednikov]

For instance, is it possible to do the following?

p := Point{10,10}
pointer := &p
println(pointer.x, pointer.y)

Yes

Why is it that a struct that is declared and initialized without the mut keyword can be passed into a receiver which will modify the fields of that struct?

This is a mistake in the docs. Fixed. Thanks :)

[ntrel]

Yes

OK, so V must prevent pointers to stack allocated structs from escaping when passed to a function. Is there an attribute e.g. @escape for marking function parameters as escapable (i.e. assigned to a receiver)?

struct S1 { s2 S2*}
fn (mut S1 s1) set_field(s2 @escape S2*) {s1.s2 = s2}

[medvednikov]

No

…

On 22 Mar 2019, at 12:23, Nick Treleaven ***@***.***> wrote: Yes OK, so V must prevent pointers to stack allocated structs from escaping when passed to a function. Is there an attribute e.g. @escape for marking function parameters as escapable (i.e. assigned to a receiver)? struct S1 { s2 S2*} fn (mut S1 s1) set_field(s2 @escape S2*) {s1.s2 = s2} — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAp_fF6K7i_Ujt-jEVNB5BctscQJLzmGks5vZL0-gaJpZM4cCnD9>.

[ntrel]

@medvednikov I presume you mean you don't want an @escape attribute, and all function parameters can't escape. This seems to work against the nice feature of immutable data that it can be referenced in multiple places (and even across threads) because it doesn't change. But I suppose that requires garbage collection or reference counting for heap allocated immutable data.

[medvednikov]

No meaning there’s no such feature. And I don’t have a solution to this problem atm.

…

On 22 Mar 2019, at 12:33, Nick Treleaven ***@***.***> wrote: @medvednikov <https://github.com/medvednikov> I presume you mean you don't want an @escape attribute, and all function parameters can't escape. This seems to work against the nice feature of immutable data that it can be referenced in multiple places (and even across threads) because it doesn't change. But I suppose that requires garbage collection or reference counting for heap allocated immutable data. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAp_fO7CEpuDZqYcLEPaOK0R8z8S84yPks5vZL9ugaJpZM4cCnD9>.

[ntrel]

I think V should prevent escapes for now, then later the restriction could be relaxed in certain cases if necessary. Otherwise it will be hard to go the other way and allow escaping now, then break code by imposing a restriction later. I guess the workaround for forcing escapes (that the programmer knows are memory safe) would be to drop into C #s1->s2 = s2.

[medvednikov]

Closing because the original questions were answered.

Escaping structs were discussed in another issue. Basically they will behave like in Go.