References can be 'owned' or 'borrowed'. They can also be 'shared' or 'exclusive' And maybe I need 'const' as well?? Borrowed references need to be borrowed from somewhere, and it must be clear where. - from a caller via function parameter passing - from a data structure via a lookup function - if structure is append-only - from a lock - which asserts ownership while held Owned references can be: refcounted - are these borrowed from the refcount? single - there is only ever one owner The difference is that 'single' uses zero bits for the refcount. So maybe if a structure has a field declared 'refcount' it is refcounted, else it can only be 'single'. A pointer is declared as name: @type Attributes can appear afterwards name: @type owned shared ownership is transferred using new := *old (??) This nulls the variable or marks it invalid. An assignment like new : @type = old will create a new owned reference and is only permitted for refcounted Owned references are dropped when they are replaced or go out of scope. This results in a dec of refcount and possible a free - or "close" once I have objects. When a reference is borrowed I need to know where it is borrowed from. The owner can be some other (complex) object or the call stack. It might be some set of objects if we don't know for certain. What are some difficult pointer usages that need clear understanding. 1/ linked lists and trees are easy. The link is owned. 2/ double-linked lists have two problems. A/ The 'prev' link cannot be owned - so who is it borrowed from? B/ The tail link back to the header. The links aren't where the ownership resides. The ownership resides in the total data structure - the list. The list - represented by the head - owns the references to all members. The pointers are just record keeping. Pointers *can* store ownership, but they are just one option. A function can declare that some ownership is stored or released without the language being able to confirm it. I need to write some code to explore what I want. A ref is dereferenced with '@', but it can be left off if there is a field reference, so "ref@.foo" and "ref.foo" are the same. ref@new allocates a new object ref@valid is true if the ref points to something ref@drop drops the ref and invalidates the pointer ?? Maybe foo:@type = @new() foo = @null foo? ---- I wonder if I want user-defined reference attributes. This would require generic support in the language. The idea is that the language gurantees some simple properties and the code provie the manipulations. So the "owned" attribute is declared as 'single' meaning it isn't copied with the pointer. However it can be explicitly copied by a "get_ref" function which returns an 'owned' flag without consuming one. Some attributes would be "sticky" meaning they follow a value around. "mut" or "ro" would be like this. Some fields in an object may only be accessed or changed by a method, which may explicitly change flags. "ro" might prevent updates, "mut" might permit them, "hidden" might prevent all accesses, or "xray" might be needed to see anything. Attributes could define trigger functions which are called in certain circumstances. "owned" might call free() when the value goes out of scope without being consumed. Tracking the connection between "owned" and "borrowed" might be tricky. I need some code to play with.