How do safe Reference and List work together?
From my understanding
Reference
is just a pointer in memory with associated lifetime. But I don't understand how the following code doesn't crash
Certainly reallocation should have happened here and therefore element
should point to invalid memory location, which should cause segfault. But it prints 0
. What am I missing?23 Replies
On latest nightly:
But why doesn't it segfault?
Or maybe even more precise questions are:
1. Does this code has well defined behaviour?
2. If yes, how does this work? If not, then how safe is safe Reference?
I'm interested in understanding this as well. @Owen Hilyard can you help?
This looks like a compiler bug, the existence of
element
should prevent calling list.append
.Why should it prevent it? I haven't found anything about it in docs
Mutable xor Alias. You need to mutate the list to append to it, but doing there is an alias to a list element (
element
), which means mutation should not be allowed until element
is dropped.Congrats @Owen Hilyard, you just advanced to level 24!
That's the property that provides memory safety and data race safety to both Mojo and Rust.
What makes smth an Alias?
Congrats @blblblbl, you just advanced to level 1!
If there are multiple references to it. Calling any method takes a reference to
self
, so should only be able to call methods which can't change the list in any way until you no longer have a pointer into the list.
The Pointer[is_mutable=False, T]
type is closer to const &T
in C++. UnsafePointer is like T*
. Pointer[is_mutable=True, T]
is &T
.But we have mutable reference to a value inside UnsafePointer inside a List. Should compiler understand that this reference is also an alias for List?
Collections are supposed to return a type which has a reference tied to
self
. It looks like Pointer
is not actually handing that information correctly.In my original question I used
Reference(list[0])
. __getitem__
of list returns a ref [__lifetime_of(self)] T
, so I guess there is no room to have reference to self
So, should __getitem__
return something else more complex, that has reference to self
?__lifetime_of(self)
is the correct behaviorSo
__lifetime_of(self)
should already provide information to compiler that Reference(list[0])
is an Alias to list
?Yes
Got you, thx! Probably it is a good idea to write in docs about aliases and the fact that
lifetime
not only manages value lifetime but also controls aliasingThere was a big rewrite of a bunch of these semantics a week or two ago, so docs are waiting for experimentation to end.
On a side note, should I make an issue in Github about this?
Please do, I was about to start filing it.
GitHub
[BUG] Compiler doesn't prevent mutation of an aliased variable · Is...
Bug description Compiler doesn't prevent mutation of a List variable using append method, when a Reference to a list element exists Link to discussion in Discord: link Steps to reproduce fn mai...
Thank you