On 12/14/2014 5:44 PM, Dicebot wrote:
I am looking for a tool to prevent escaping references to user-defined entities
/ resources from specific scope. RC case is not interesting at all to me though
I recognize the potential benefits of tweaking the scope system to help with it.
But there is a big difference between tweak for one specific use case or
designing feature around it (so it becomes almost useless in other cases).

I have already provided you an example of code I want to be enforced with scope
and two major issues with existing proposal that make it lacking. This example
is akin to litmus test for any scope proposal - if it doesn't allow to express
such design, that proposal is simply not good enough.

In case you have forgotten, I am reminding about two critical points that are
necessary to make it fly:

1) inout analog for scope to be able to deduce borrowship of return values based
on borrowship of input arguments. Current system is conservative and results in
template bloat (complicated by the fact that it is storage class thus not
actually part of a type)

1. All inout actually does is reduce code copy/pasta, it is not critical.
2. This is what scope inference is all about.


2) at least optional transitivity to be able to express to protect with scope
data referenced by slice or owned linked list referenced from root node.

1. that won't work unless scope is a type constructor
2. it can be achieved by using wrappers that only allow by-scope references to their data (RC is an example of such a wrapper)


In your tree example I would have never wanted scope protection of one specific
node of such tree - but a transitive scope protection of whole tree view
available through on of node pointers/references. It doesn't matter who and how
owns the data for borrowship implementation - only thing that matters that _it
is not me_.

As I explained to Manu, transitive scope makes things like doing a symbol table lookup, then putting a pointer to the found symbol in an AST, not workable.

Reply via email to