Markus Gerwinski wrote:
Maybe I'm just playing devil's advocate here, but I really don't see any advantage of the concept yet (except maybe in rather special situations such as those that Markus has in mind with his collections IIUIC) ...
They're quite common situations, at least in object-oriented programming: You often have some object stored in, e.g., a list, referenced from three other lists with other sorting criteria, plus two trees sorting the object into different hierarchies, plus a hashtable of completely other objects referencing the first one in a bunch of associations etc. etc. etc.. Keeping the overview of who is when allowed to destroy which object often becomes an act of complex logics. It is either a quite common pattern to keep track of your "stores" and "references". (A most common example are existence- dependent or -independent associations in UML.) My suggestion was to make this pattern an inherent part of the compiler.
So IIUIC the special pattern in "your" usage is that one kind of lists only contains "store" pointers and other lists contain only "reference" pointers? (Otherwise, you wouldn't be able to even declare the lists if the pointers were distinguished syntactically, AFAICS.)
Well, I think that is a rather special pattern. In most of my code (and even more so in GCC/GPC), many "objects" contain a wild mix of original ("store") and copied ("reference") pointers.
BTW, I just noticed an analogy, namely to file systems: While normal pointers are like hard links, your reference pointers are like symlinks. I'm not sure, though, what this means to this discussion. ;-) -- But perhaps the analogy is not so good, since symlinks remain in existence if you remove the target, and if you create a new target under the same name, they point to this one.
Frank