gistfile1.txt

"If a language only allowed owning references, memory management would betrivial, but ownership rules would severely limit the programmer."

Now that I think of it, this would just be a lot of copies. In fact, someone has tried something like this: https://degaz.io/blog/632020/post.html


"1.2.2 Borrow References". The term "borrow references" is fine, but might want to make it clear up front that they don't work like Rust's borrow references. Or sometimes, I call them non-owning references, to avoid confusion.


"while C++ uses the unique_ptr and shared_ptr classes mentioned in 1.1.1 to accomplish the same goal." -> "while C++ uses unique_ptr and raw pointers respectively mentioned in 1.1.1 to accomplish the same goal.
(shared_ptr is for RC in c++, and shared_ptr and unique_ptr dont mix)


1.3 Variability is empty, im sure you already know


for clarity
"Generation num-bers are assigned to chunks of memory; each number starts at zero and increasesmonotonically." ->
"Each chunk of memory has a generation number, which starts at zero and increases monotonically."


for clarity
"object’s current generation number, called the target generation." -> "object’s current generation number, this copy is called the called the target generation."


"what  makes  the  schema  fast" -> "what  makes  the  scheme  fast" ?



" Static  analysis  in  Vale  identifies  manypatterns  that  are  not  allowed  in  Rust,  because  these  often  require  generationchecks in Vale."
maybe:
"Just like how Rust identifies and enforces memory-safe patterns, Vale's static analysis will identify similar patterns, and remove their generation checks."


" that were briefly introduced in ??" lol


"mutable borrow references can only be created from mutable owning references" i personally think of it this way, but it might not be correct rust terminology, i dont think they consider "owning references" to really be references. but, your characterization does actually make it easier to draw parallels with vale (i see what you did there) so i could see leaving it in


"Arrays  and  structs  are  mutable  in  Vale" -> "Arrays  and  structs  are  by default mutable  in  Vale"


in fig 3.3, lets explicitly put in the drop, for clarity:
  x = b.fuel;
  drop(s);
  ret x;


lol @ using Spaceship for your examples, glorious


"variable b points to object 0 "
maybe label a 0 in fig 3.5


clarity
"When Catalyst parses the AST node for  this  borrow  reference," -> "When Catalyst parses the AST node that creates this  borrow  reference from the variable,"


clarity
"The reason for thisis that a borrow reference can be a member of multiple objects, but an owningreference can only be a member of one object at a time."
->
"The reason for this is that an object can have multiple borrow references pointing at it, but it can only be owned by one owning reference, which lives in either a local or an object."
(i think? maybe i made it worse)

"the Parent value of its referend is not updated." -> "the Parent value of its referend is normally not updated."


"all references within an argument’s object generate a new entry in the Objects table."
watch out for aliasing
see strict aliasing: https://www.geeksforgeeks.org/strict-aliasing-rule-in-c-with-examples/


"The function can only access these objects through the parent argument object,and therefore can only generate borrow references to them.  Borrow referenceswill never allow ownership to be moved, so the parent of these objects can neverchange in the function’s scope."
not quite true, if they passed in an object which owns it via a varying owning field, its parent can be changed


"and theReturnArgattributeof theReturnInfoinstance forduplicateShip3tells Catalyst that the objectwas not passed as an argument" is actually not relevant, since it was an owning reference. any owning reference is guaranteed to be knownLive true, because we have the owning reference


"Catalyst will change the object’sLivenessvalue to ’false’ in thecaller’s  scope" perhaps add "because the callee might have destroyed it."
oh, nevermind, you say it a couple sentences later


"The callee can only access these objects via an argument, whichwill  generate  a  borrow  reference."
did you mean "via a borrow reference"?


"As with final owning references, if a varying owning reference is nested in anargument, its referend’sLivenessvalue will not change.  The callee will only beable to access the referend via borrow references which can be pointed to newobjects, but will not destroy the old object."
im not sure this is true, if i have a readwrite borrow to an object, i can change its owning ref field to point to a different object
(it might also be not true because of the whole strict aliasing thing)