On Friday, 12 December 2014 at 06:06:40 UTC, Dicebot wrote:
> On Thursday, 11 December 2014 at 21:41:11 UTC, Walter Bright wrote:
>> Consider a ref counted type, RC!T. If scope were transitive, then you could not have, say, a tree where the edges were RC!T. I.e., the payload of an RC type should not be forced to be scope.
>
> I don't see how this is related. It would be perfectly ok to declare root of such tree scope if it was transitive (as long as it only controls access and does not attempt early destruction).
>

That is my proposal. However, it is not as simply as you think it is without making it a type qualifier (which is not desirable).

In effect, that mean that you can see something that has infinite lifetime through a scope reference, so you need to track lifetime rvalue and lvalue differently.

I'm still for it. The current proposal is not powerful enough to pull its weight.

On Thursday, 11 December 2014 at 23:26:33 UTC, deadalnix wrote:
> I have no idea what you are saying. It sounds like randomly generated gibberish.

What is your problem?

Scope parameters are trying to address what Rust tried to do with borrowing. To get an idea of where you are going you should look at ordered linear and non-linear type systems.

Without a dynamic solution OR a proof system OR a way to provide a manual guarantee you will hit the ceiling for what you can do, which will be annoying for the user (programmer).

On 12/11/2014 10:06 PM, Dicebot wrote:
> On Thursday, 11 December 2014 at 21:41:11 UTC, Walter Bright wrote:
>> Consider a ref counted type, RC!T. If scope were transitive, then you could
>> not have, say, a tree where the edges were RC!T. I.e., the payload of an RC
>> type should not be forced to be scope.
>
> I don't see how this is related. It would be perfectly ok to declare root of
> such tree scope if it was transitive (as long as it only controls access and
> does not attempt early destruction).

Are you suggesting two kinds of scope - transitive and non-transitive?

The more I think about it, the more ref counting is the definitive case, as just about everything else can be explained in terms of how ref counting works.

On Friday, 12 December 2014 at 07:48:21 UTC, Walter Bright wrote:
>> I don't see how this is related. It would be perfectly ok to declare root of
>> such tree scope if it was transitive (as long as it only controls access and
>> does not attempt early destruction).
>
> Are you suggesting two kinds of scope - transitive and non-transitive?
>
> The more I think about it, the more ref counting is the definitive case, as just about everything else can be explained in terms of how ref counting works.

I don't see applicability of non-transitive scope because I don't understand the problem with the tree or reference counting you have mentioned - that is why I suggested to amend DIP to put explanation there.

On Friday, 12 December 2014 at 06:57:54 UTC, deadalnix wrote:
> On Friday, 12 December 2014 at 06:06:40 UTC, Dicebot wrote:
>> On Thursday, 11 December 2014 at 21:41:11 UTC, Walter Bright wrote:
>>> Consider a ref counted type, RC!T. If scope were transitive, then you could not have, say, a tree where the edges were RC!T. I.e., the payload of an RC type should not be forced to be scope.
>>
>> I don't see how this is related. It would be perfectly ok to declare root of such tree scope if it was transitive (as long as it only controls access and does not attempt early destruction).
>>
>
> That is my proposal. However, it is not as simply as you think it is without making it a type qualifier (which is not desirable).
>
> In effect, that mean that you can see something that has infinite lifetime through a scope reference, so you need to track lifetime rvalue and lvalue differently.
>
> I'm still for it. The current proposal is not powerful enough to pull its weight.

I don't hope it will be simple. It is all about making scope as simple as possible to keep it useful for idiomatic D code - but not simpler.

On Friday, 12 December 2014 at 07:48:21 UTC, Walter Bright wrote:
> Are you suggesting two kinds of scope - transitive and non-transitive?
>

Non transitive scope can be added without any language extension. There is no point doing much with the scope keyword if indirection aren't in the loop.

> The more I think about it, the more ref counting is the definitive case, as just about everything else can be explained in terms of how ref counting works.

ref counting is just one form of ownership.

On 11 December 2014 at 23:22, ixid via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Manu have you shown Walter some of the code where ref is problematic? He seems to have asked to see examples repeatedly as he's not convinced there is a problem.

I have discussed issues here in the past, but possibly not as
concretely as would be useful to this discussion.
I want to take some time to contribute value to this issue, but I have
virtually no time at all lately, and I can't even keep up with this
posts thread, let alone sit and consider+craft a bunch of
demonstration cases.
This thread is moving faster than I am able to, so I'm not sure what I can do.

There's no TL;DR conversation, and almost all discussion happens
outside of my timezone, which wasn't such a problem when I was
nocturnal, but I have had to change lifestyle recently :/
I have about 30 posts to try and catch up on and understand right now
in 5 minutes before I have to leave >_<

On 12/11/2014 11:55 PM, Dicebot wrote:
> On Friday, 12 December 2014 at 07:48:21 UTC, Walter Bright wrote:
>>> I don't see how this is related. It would be perfectly ok to declare root of
>>> such tree scope if it was transitive (as long as it only controls access and
>>> does not attempt early destruction).
>>
>> Are you suggesting two kinds of scope - transitive and non-transitive?
>>
>> The more I think about it, the more ref counting is the definitive case, as
>> just about everything else can be explained in terms of how ref counting works.
>
> I don't see applicability of non-transitive scope because I don't understand the
> problem with the tree or reference counting you have mentioned - that is why I
> suggested to amend DIP to put explanation there.

Consider every pointer in a tree to be a ref counted pointer. There is no purpose to making scope transitive - traveling from one node to the next goes through the usual ref counting mechanism, and the ref counting wrapper can control that.

Also, consider a data structure:

A -> B
C -> B

If scope is transitive, how is C going to simultaneously access B?

On 11 December 2014 at 23:55, via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Thursday, 11 December 2014 at 12:48:05 UTC, Manu via Digitalmars-d wrote:
>>
>> On 8 December 2014 at 07:29, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On 12/7/2014 6:12 AM, Dicebot wrote:
>>>>
>>>>
>>>> But from existing cases it doesn't seem working good enough. For
>>>> example,
>>>> not
>>>> being able to represent idiom of `scope ref int foo(scope ref int x) {
>>>> return x;
>>>> }` seems very limiting.
>>>
>>>
>>>
>>>   scope ref int foo(ref int x);
>>>
>>> will do it.
>>
>>
>> Will it? It looks like foo can't be called with scope data?
>
>
> This is a point that most people don't seem to understand yet, and which wasn't obvious for me either, at the beginning:
>
> * A `ref` parameter means that it cannot escape the function, _except_ by
> return.
> * A `scope ref` parameter means that it cannot escape the function  _ever_,
> not even by return.
> * A `scope ref` return means that it cannot leave the current statement.
>
> Therefore, a `scope ref` return value can be passed on to the next function as a `ref` argument. If that function again returns a reference (even if not explicitly designated as `scope`), the compiler will treat it as if it were `scope ref`.

Ummm. I reckon there's a good reason that people don't seem to
understand this... because it would have difficulty being any more
unintuitive!
It's contrary to the behaviour of basically everything else in D!
const, pure, nothrow, etc... they all work a reliable and consistent way.

Also, I still don't think I get it... a scope-ref return, which has a
restriction as you say, can be subverted by being piped through a
function that receives and returns it as ref?
What is the point?

>> I'm also quite uneasy with the fact that scope would not be transitive as a storage class. What happens when it's applied to a value type, like a struct, that contains some pointers? An adaptation wrapper for a single pointer is super common; ie, a tiny struct passed by value with scope needs to have it's contained pointer receive the scope-ness of the argument.
>
>
> I agree, this is important. In my proposal, this works without transitivity. The wrapper stores the pointer as a `scope` member, then by copying the wrapper, the pointer gets copied implicitly, to which the normal scope restrictions apply (`scope` on members means "will not outlive the aggregate"). If it stored it as normal non-scope pointer, it couldn't get assigned in the first place. (Additionally, some higher level tricks are possible if we allow scope for value types and overloading on scope.)

How can a member be marked scope? Apparently it's a storage class, not a type constructor... we can only attribute storage classes to function args/results(?).

On 12/12/2014 12:16 AM, deadalnix wrote:
> On Friday, 12 December 2014 at 07:48:21 UTC, Walter Bright wrote:
>> Are you suggesting two kinds of scope - transitive and non-transitive?
>>
>
> Non transitive scope can be added without any language extension.

In order for it to work, the holes in the language that enabled escapes had to be plugged. That's what this proposal does - plug the holes.


> ref counting is just one form of ownership.

My point is if that works with this proposal, then the other forms can work, too.