On 11/01/2016 04:34 AM, Walter Bright wrote:
> Yeah, sorry, the 'return' is necessary as you said.

Great, this brings my understanding back to state of harmony again :)

On Tuesday, 1 November 2016 at 09:19:55 UTC, Walter Bright wrote:
> I implemented it, but now the PR got thoroughly fouled up after I rebased it on master.

You need help fixing this? In case of failed rebases it's usually best to git rebase --abort. If it's too late for that, you cat look at .git/logs/refs/heads/branch_name, to find the git commit hash before the rebase, then git reset --hard to that, and try again.

On 11/5/2016 3:58 AM, Martin Nowak wrote:
> On Tuesday, 1 November 2016 at 09:19:55 UTC, Walter Bright wrote:
>> I implemented it, but now the PR got thoroughly fouled up after I rebased it
>> on master.
>
> You need help fixing this? In case of failed rebases it's usually best to git
> rebase --abort. If it's too late for that, you cat look at
> .git/logs/refs/heads/branch_name, to find the git commit hash before the rebase,
> then git reset --hard to that, and try again.

I'm concerned that if I dink around with it, I might wind up scrambling/deleting the commit history of it. I'd rather learn this stuff on something less important, so I'd prefer to defer it to you.

Now that we have https://github.com/dlang/dmd/pull/6253 I came back to test it a bit.

First I have a question: What is going to happen with `scope foo = new Object` ?
Are we keeping it the way it currently is ? It's something we highly rely on at work and it looks like it could work nicely with the enhancements, but it wasn't mentioned anywhere.

And from a quick test (Using `-dip25 -transition=safe` and 5928249 which is the commit of this P.R.), the following code:

```
void main () @safe
{
    scope o = new Object();
}
```

Results in the following error:
scope2.d(3): Error: delete o is not @safe but is used in @safe function main

Which works with the compiler I'm currently using, 2.071.2.

By the way, I reiterate my point that tying `scope` verification to `@safe` function is highly misleading and not necessary. I originally crafted a couple of test case, and when everything worked, I was left puzzled for a minute before realizing I forgot `@safe`.

Second point, on testing your P.R., I found that the following code compiles:

```
alias FunDG = void delegate () @safe;

void main () @safe
{
    int x = 42;
    scope FunDG f = () { assert(x == 42); };
    return fun(&f);
}

FunDG fun (scope FunDG* ptr) @safe
{
    return *ptr;
}
```

As well as the following:
```
alias FunDG = void* delegate () @safe;

void main () @safe
{
    void* x = fwd();
}

void* fwd () @safe
{
    int x = 42;
    scope FunDG f = () { return &x; };
    return fun(f);
}

void* fun (scope FunDG ptr) @safe
{
    return ptr();
}
```

I'm not quite sure how one would express taking a pointer to a scope value though.

On Sunday, 16 October 2016 at 13:45:42 UTC, Dicebot wrote:

To summarize the current state, the Skype call with Walter cleared most of the misunderstandings, DIP1000 is about 2 simple points.

- make scope work (fix all escaping whatsoever)

It's more complex than return ref because pointers, other than references, can be bound to variables, hence the lifetime algebra.

Since it was already possible to create pointers in @safe code (ubyte[] a
= staticArray[];), and we finally can prevent escaping of pointers,
DIP1000 also includes allowing to take the address of sth. in @safe
code, similarly to how &ary[$] is now possible (see https://github.com/dlang/dmd/pull/6253).

- add return scope to allow returning scoped arguments (or sth. derived
from them)

The current state is to conservatively assume the return value has the
minimum lifetime of all return scope parameters (no smartness about
possible aliasing of return value to parameters), even for @trusted
functions. This should enable RC/Unique like patterns or ranges on
containers.

- Adding scope inference for parameters and variables, we already have return inference from DIP25.

Inference will make this actually usable, otherwise we'd end up with a huge amount of required extra annotations.

====================

Open questions from my side:

- what about unwanted/incorrect return scope inference

Mixed return branches would conservatively assume a scoped return value?
Is this a valid use-case? Should at least work with @system code.

int* func()(int* arg, bool allocate)
{
    return allocate ? new int : arg;
}

- what about return ref without scope

Does return ref on parameters makes sense without scope?
Can you take the address of an unscoped return ref result?

On 11/20/2016 8:41 AM, Mathias Lang wrote:
> First I have a question: What is going to happen with `scope foo = new Object` ?
> Are we keeping it the way it currently is ?

Yes.


> void main () @safe
> {
>     scope o = new Object();
> }
> ```
>
> Results in the following error:
> scope2.d(3): Error: delete o is not @safe but is used in @safe function main
>
> Which works with the compiler I'm currently using, 2.071.2.

I'll look into that.


> By the way, I reiterate my point that tying `scope` verification to `@safe`
> function is highly misleading and not necessary.

I understand your point. The trouble is, it will break too much code.


> I found that the following code compiles:
>
> ```
> alias FunDG = void delegate () @safe;
>
> void main () @safe
> {
>     int x = 42;
>     scope FunDG f = () { assert(x == 42); };
>     return fun(&f);
> }
>
> FunDG fun (scope FunDG* ptr) @safe
> {
>     return *ptr;
> }
> ```

I get:

bug9.d(7): Error: cannot return non-void from void function


> As well as the following:
> ```
> alias FunDG = void* delegate () @safe;
>
> void main () @safe
> {
>     void* x = fwd();
> }
>
> void* fwd () @safe
> {
>     int x = 42;
>     scope FunDG f = () { return &x; };
>     return fun(f);
> }
>
> void* fun (scope FunDG ptr) @safe
> {
>     return ptr();
> }

I'll have to investigate that one.

On 11/20/2016 8:41 AM, Mathias Lang wrote:
> And from a quick test (Using `-dip25 -transition=safe` and 5928249 which is the
> commit of this P.R.), the following code:
>
> ```
> void main () @safe
> {
>     scope o = new Object();
> }
> ```
>
> Results in the following error:
> scope2.d(3): Error: delete o is not @safe but is used in @safe function main
>
> Which works with the compiler I'm currently using, 2.071.2.

This was done here back in June:

  https://github.com/dlang/dmd/commit/e64ae1d3e5aa078a036242864a68499617c9b278

and was added to fix:

  https://issues.dlang.org/show_bug.cgi?id=16195

The trouble is, operator delete is not safe.

What do you suggest?

On Wednesday, 23 November 2016 at 03:25:20 UTC, Walter Bright wrote:
> I understand your point. The trouble is, it will break too much code.

Maybe I am missing something here: I didn't consider it as breaking more code than it's `@safe` counterpart.

>> I found that the following code compiles:
>> [...]
> I get:
>
> bug9.d(7): Error: cannot return non-void from void function

My bad, I tried to reduce the snippet a bit more and broke it :)
Here's the corrected version:

```
void main () @safe
{
    int x;
    void* escape = bar(&x);
}

void* bar (scope void* x) @safe
{
    return fun(&x);
}

void* fun (scope void** ptr) @safe
{
    return *ptr;
}
```

Using the top of your branch, that is:
b8df860 allow 'return' attribute on nested functions (68 minutes ago) <Walter Bright>

On Wednesday, 23 November 2016 at 03:35:16 UTC, Walter Bright wrote:
> On 11/20/2016 8:41 AM, Mathias Lang wrote:
>> And from a quick test (Using `-dip25 -transition=safe` and 5928249 which is the
>> commit of this P.R.), the following code:
>>
>> ```
>> void main () @safe
>> {
>>     scope o = new Object();
>> }
>> ```
>>
>> Results in the following error:
>> scope2.d(3): Error: delete o is not @safe but is used in @safe function main
>>
>> Which works with the compiler I'm currently using, 2.071.2.
>
> This was done here back in June:
>
>   https://github.com/dlang/dmd/commit/e64ae1d3e5aa078a036242864a68499617c9b278
>
> and was added to fix:
>
>   https://issues.dlang.org/show_bug.cgi?id=16195
>
> The trouble is, operator delete is not safe.
>
> What do you suggest?

If I understand correctly, it's not @safe because it might free a reference which is still used elsewhere, making it dangling.

If we have the correct `scope` enforcement though, we can allow it *only at the scope which `new`ed it*, because we know it's not possible than any other place has a reference to it, as the reference would have to be `scope` as well.

Does that make sense ?

On 11/22/2016 7:25 PM, Walter Bright wrote:
>> As well as the following:
>> ```
>> alias FunDG = void* delegate () @safe;
>>
>> void main () @safe
>> {
>>     void* x = fwd();
>> }
>>
>> void* fwd () @safe
>> {
>>     int x = 42;
>>     scope FunDG f = () { return &x; };
>>     return fun(f);
>> }
>>
>> void* fun (scope FunDG ptr) @safe
>> {
>>     return ptr();
>> }
>
> I'll have to investigate that one.

I amended:

https://github.com/dlang/dmd/pull/6253

to fix it.