On Monday, 15 December 2014 at 01:44:27 UTC, Dicebot wrote:
On Saturday, 13 December 2014 at 00:10:07 UTC, Walter Bright
wrote:
The proposal provides escape proof passing of arguments. This
is necessary in order to make rc safe, for example.
What are you looking for?
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)
Is it be possible to make `inout` a more general tool for type
erasure? I don't think yet another ad-hoc mechanism should be
introduced.
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.
------
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_.
I think there are two cases that are relevant. 1) the tree nodes
don't own their children, instead they are managed by - let's say
- a region allocator, and 2) the tree nodes do own their
children. In both cases, they can declare the children as scope
members (assuming a proposal that allows that).
The only case I can think of where the children should not be
scope members is when they are GC managed. But in this case, you
don't need to worry about references to them escaping.
Therefore, I don't see a use case for transitivity of scope, from
a conceptional point of view. If a particular design makes
transitivity necessary, this points to a flaw in the design, IMO.
