From ed7da0d9e31e8dd6847e2e603f0d1943330cf4d0 Mon Sep 17 00:00:00 2001 From: Kimplul Date: Fri, 13 Mar 2026 14:07:29 +0200 Subject: 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. --- TODO | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) (limited to 'TODO') 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). -- cgit v1.2.3