On 10/16/2016 03:45 PM, Dicebot wrote:
> Trying to solve it, I have been experimenting lately with various acceptance tests trying to come up with useful design snippets enabled by that PR. Rationale is that if actual semantics are clear and examples are all validated as included test cases, review of the code itself becomes less important.
> 
> I'd like to have more open feedback about it because in its current shape PR5972 doesn't seem useful enough to me to be merged at all - and much less powerful than DIP1000 seemed to promise.
> 
> I'll start separate sub-threads with more details.


Just build a scope preview, http://nightlies.dlang.org/dmd-scope/.

You can just download it or use

    curl -fsS https://dlang.org/install.sh | bash -s dmd-scope

to try it (also works on Travis-CI anything else using the install.sh
script).

-Martin

On Tuesday, 20 December 2016 at 00:15:23 UTC, Martin Nowak wrote:
> On 10/16/2016 03:45 PM, Dicebot wrote:
>> Trying to solve it, I have been experimenting lately with various acceptance tests trying to come up with useful design snippets enabled by that PR. Rationale is that if actual semantics are clear and examples are all validated as included test cases, review of the code itself becomes less important.
>> 
>> I'd like to have more open feedback about it because in its current shape PR5972 doesn't seem useful enough to me to be merged at all - and much less powerful than DIP1000 seemed to promise.
>> 
>> I'll start separate sub-threads with more details.
>
>
> Just build a scope preview, http://nightlies.dlang.org/dmd-scope/.
>
> You can just download it or use
>
>     curl -fsS https://dlang.org/install.sh | bash -s dmd-scope
>
> to try it (also works on Travis-CI anything else using the install.sh
> script).
>
> -Martin

That's great Martin! What's the delay between a PR merged in https://github.com/dlang/dmd/tree/scope and being available for testing via the installer? Is it a nightly build of the scope branch, as the URL suggests?

On Sunday, 18 December 2016 at 17:56:26 UTC, Walter Bright wrote:
> On 12/18/2016 9:28 AM, Martin Nowak wrote:
>> Let me suggest a reason, transitive scope checking would be more complex
>> to implement, is it that?
>
> It's a heluva lot more complicated for the user. And since it is not necessary, why pay such a large bill?
>
>
>> - How certain are we that this is enough? In other words, why is `tmp =
>> &a.b; tmp2 = &tmp.c; tmp2.d.e` not necessary.
>
> It would be necessary in order to build non-trivial data structures on the stack. How necessary is that? I've never needed to in decades of programming. I don't think there are any instances in Phobos or dmd.
>
> If one really wants to do that, there's always @system code.
>
> Is it worth burdening everything with a feature when the use case for it is rare? I don't think so.
>
> For example, consider 'volatile' in C++. The use case for it is rare (very rare). But there's an enormous amount of spec verbiage and thought dedicated to how to weave it into the type system, overloading rules, conversion rules, casting rules, promotion rules, mangling rules, deduction rules, on and on. It's just not worth it.
>
>
>> - Let's imagine for a short moment, what it would mean to make scope
>> transitive at a later point, if we'd ever find enough reasons to do so.
>> Maximizing future options is always good.
>
> This kind of annotation system was first proposed 10 years ago. I've been thinking about how to make it simpler ever since, and the original has not improved with age.
>
> I also have a lot of experience with transitive const, and how disruptive that was, and how many years it took to work the problems out (Andrei says they're still a problem).


Thank you so much for this explanation.
It clears up many of the points on which I had questions.
Once I run out of simple test cases, I'll try to toy around with a more advanced RefCounted design.

On Wednesday, 21 December 2016 at 13:48:11 UTC, ZombineDev wrote:
> That's great Martin! What's the delay between a PR merged in https://github.com/dlang/dmd/tree/scope and being available for testing via the installer? Is it a nightly build of the scope branch, as the URL suggests?

Preview builds of branches are manually build at the moment (whenever there is sth. interesting).
Nightlies are only for master atm.

On Sunday, 18 December 2016 at 15:25:55 UTC, Walter Bright wrote:
> On 12/18/2016 3:09 AM, Mathias Lang wrote:
>> With the two last P.R. you submitted merged, the following compiles
>>
>> ```
>> void escape () @safe
>> {
>>     Foo f;
>>     bar(f);
>> }
>>
>> void bar (scope ref Foo f) @safe
>> {
>>     int[10] i;
>>     f.v = i;
>> }
>>
>> struct Foo
>> {
>>     int[] v;
>> }
>> ```
>
> Thanks, I'll look at it tomorrow.

Just tested again with the HEAD of scope (e46873f66), it compiles with just `ref` instead of `scope ref` for bar's parameter.
Which brings me to the question, is `scope ref` supposed to apply to the `ref` or to the type (i.e. `Foo` in this case) ?

On 12/27/2016 2:18 PM, Mathias Lang wrote:
> Which brings me to the question, is `scope ref` supposed to apply to the `ref`
> or to the type (i.e. `Foo` in this case) ?

scope refers to the parameter's value, ref refers to the parameter's address. The two are independent of each other.

On Wednesday, 28 December 2016 at 01:25:22 UTC, Walter Bright wrote:
> On 12/27/2016 2:18 PM, Mathias Lang wrote:
>> Which brings me to the question, is `scope ref` supposed to apply to the `ref`
>> or to the type (i.e. `Foo` in this case) ?
>
> scope refers to the parameter's value, ref refers to the parameter's address. The two are independent of each other.

Thanks (Y)

I just started testing methods, but didn't get far, because the following doesn't compile:
```
void getObj () @safe
{
    scope o = new Bar;
    auto p = o.foo;   // Line 9
}

class Bar
{
    Object foo () return scope @safe { return this; }
}

// scope1.d(9): Error: scope variable o assigned to non-scope parameter this calling scope1.Bar.foo
```

However making `foo` a function which accept a class works:
```
Object foo (return scope Object this_) @safe
{
    return this_;
}
```

Also, it looks like delegates to member functions are not marked scope where they should. The following compiles, but obviously should not since the context pointer of the delegate will be the instance `b`, which is on the stack.

```
void main () @safe
{
    fwd();
    auto x1 = Generator1();
    auto x2 = Generator2();
}

int delegate() @safe Generator1;
int delegate() @safe Generator2;

struct G1
{
    int generator () @safe { return 42; }
}

class G2
{
    int generator () @safe { return 42; }
}

void fwd () @safe @nogc
{
    G1 g1;
    scope g2 = new G2;
    Generator1 = &g1.generator;
    Generator2 = &g2.generator;
}
```

Thanks, I'll look into these.

On 12/30/2016 01:12 PM, Mathias Lang wrote:

Can we please start to track all DIP1000 implementation bugs on Bugzilla. It's becoming quite chaotic to keep an overview of this. Until someone creates a scope or dip1000 keyword (does @braddr maintain Bugzilla), we can use [scope] in the title, that's search-able.

https://issues.dlang.org/buglist.cgi?list_id=212784&query_format=advanced&resolution=---&short_desc=%5Bscope%5D&short_desc_type=substring

On 12/31/2016 05:18 PM, Martin Nowak wrote:
> On 12/30/2016 01:12 PM, Mathias Lang wrote:
> 
> Can we please start to track all DIP1000 implementation bugs on Bugzilla. It's becoming quite chaotic to keep an overview of this. Until someone creates a scope or dip1000 keyword (does @braddr maintain Bugzilla), we can use [scope] in the title, that's search-able.
> 
> https://issues.dlang.org/buglist.cgi?list_id=212784&query_format=advanced&resolution=---&short_desc=%5Bscope%5D&short_desc_type=substring


Just filed the first one, https://issues.dlang.org/show_bug.cgi?id=17049.