add initial reference invalidation

+ Makes vec example actually memory safe, which is cool

+ Specify owner > sub relationships with ">" in closure parameter
  lists, uses the same group idea as closure calls

+ Relies on users implementing functions in a consistent manner,
  since you can kind of do whatever with pointers. Presumably
  there would be a stdlib of vec/map/set etc. which applications
  could then use and by proxy be memory safe. Although some more
  checks wouldn't hurt, I suppose?

+ Not sure I like having reference invalidation be 'just a move',
  seems to work alright but the semantics of it are a bit muddy.

1 files changed, 24 insertions, 0 deletions

diff --git a/TODO b/TODO
index e1c6a24..9368f6f 100644
--- a/TODO
+++ b/TODO
@@ -25,3 +25,27 @@ or the current alternative
 	} => ;
 
 	use (var);
+
+
++ Hmm, some kind of way to say 'this thing owns this reference' would be good.
+At the moment, I'm thinking something that parameter lists can be extended with
+ownership rules, so for example
+
+	at_vec(vec v, u64 i, (vec > &i64) ok)
+
+would return a 'new' vector and a reference into the vector. If the 'vec' is
+moved, the &i64 is marked invalidated, but the &i64 is allowed to be passed
+around as long as 'vec' is not moved.
+
+For more references, something like
+
+	hmm((owner > thing1 | thing2))
+
+is three parameters, thing1 and thing2 are both
+invalidated if owner is moved (getting two indexes from a vector to swap them?
+not sure). Not sure how complex this system should be, could there for example
+be a situation where
+
+	hmm((owner > thing1 > thing2))
+
+might make sense? For now, the parser only accepts the first form, (vec > &i64).