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

--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> ---
https://github.com/dlang/dmd/pull/8504

--

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

Mike Franklin <slavo5150@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |slavo5150@yahoo.com

--- Comment #2 from Mike Franklin <slavo5150@yahoo.com> ---
Trying to dissect Walter's back-of-the-napkin description:

Example 1
---------
@safe:

int* frank(return scope int* p) { return p; }

void main()
{
    // lifetimes end in reverse order from which they are declared
    int* p;  // `p`'s lifetime is longer than `i`'s
    int i;   // `i`'s lifetime is longer than `q`'s
    int* q;  // `q`'s lifetime is the shortest

    q = frank(&i); // ok because `i`'s lifetime is longer than `q`'s
    p = frank(&i); // error because `i`'s lifetime is shorter than `p`'s
}

This works in the compiler today if both functions are declared @safe and if compiled with -dip1000:  https://run.dlang.io/is/CZ3YuU

--

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

--- Comment #3 from Mike Franklin <slavo5150@yahoo.com> ---

Example 2
---------
@safe:

void betty(ref scope int* r, return scope int* p)
{
    r = p; // (1) Error: scope variable `p` assigned to `r` with longer
lifetime
}

void main()
{
    int* p;
    int i;
    int* q;

    betty(q, &i); // (2) ok
    betty(p, &i); // (3) should be error
}

Compile with -dip1000:  https://run.dlang.io/is/t6wj71

So, I'm assuming (1) should not be an error because it depends on the lifetimes of the arguments supplied by the caller.  Correct?

--

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

--- Comment #4 from Mike Franklin <slavo5150@yahoo.com> ---
> This situation comes up repeatedly with:
> 1. constructors
> 2. property setters
> 3. put(dest, source) functions

In other words 2 and 3 are functions that return `void`.  Constructors are like `static` functions that return an object instance, so I'm not sure how the problem at hand applies to constructors.

> Annotating a parameter with `return` has been quite successful at tracking
scope dependencies from the parameter to the function return value.

The problem with that is we don't have sufficient documentation describing the semantics of `return` parameters and their relationship with `scope`.  So, I can't understand how `return` has been used in the past to solve such issues.

So `betty` returns `void`, but a `return` parameter transfers its lifetime to the function return value.  So I guess that's the nature of this issue.  How does `return` apply to a function that has no `return` type?

--

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

--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> ---
(In reply to Mike Franklin from comment #4)
> How does `return` apply to a function that has no `return` type?

If the return type is 'void', and the first parameter is by 'ref', the 'return' applies to the first parameter. That's the whole thing in one sentence.

(For member functions, the first parameter is the implicit 'this' reference.)

--

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

--- Comment #6 from Mike Franklin <slavo5150@yahoo.com> ---
As I work to understand this proposal and evaluate it I've noticed it bears resemblance to Problem Case #3 in Rust's Non-Lexical Lifetimes design in 2016:

http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-lexical-lifetimes-introduction/#problem-case-3-conditional-control-flow-across-functions

http://smallcultfollowing.com/babysteps/blog/2016/05/09/non-lexical-lifetimes-adding-the-outlives-relation/#problem-case-3-revisited

--

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

Atila Neves <atila.neves@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |atila.neves@gmail.com

--- Comment #7 from Atila Neves <atila.neves@gmail.com> ---
@Mike It applies to constructors in the same way it applies to `void` functions whose first argument is `ref` or `out`. The hidden first parameter to the constructor is a `ref` parameter: `this`.

I think a better way to describe this issue is that first parameters that are `ref` or `out` (including `this` for constructors) should be considered and treated the same as return values for other functions.

--

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

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com

--- Comment #8 from Steven Schveighoffer <schveiguy@yahoo.com> ---
Just throwing this out there, why do we need it to be the first parameter? Why not ALL ref parameters?

It makes sense for a constructor, for which there is an obvious return expectation of the `this` parameter, but anyone can devise some calling scheme by which any arguments are transferred to any other ref arguments.

Just because Phobos follows the convention of putting the "return" parameter as the first parameter, does that mean the language should require it?

--

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

--- Comment #9 from Mike Franklin <slavo5150@yahoo.com> ---
(In reply to Steven Schveighoffer from comment #8)

> Just because Phobos follows the convention of putting the "return" parameter as the first parameter, does that mean the language should require it?

I don't think that's necessarily true.  Take a look at https://dlang.org/phobos/std_algorithm_mutation.html#copy

`TargetRange copy(SourceRange, TargetRange)(SourceRange source, TargetRange
target)`

Is copy an exception?

I recently asked about this convention at https://github.com/dlang/druntime/pull/2264#pullrequestreview-143076892

--

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

--- Comment #10 from Mike Franklin <slavo5150@yahoo.com> ---
Some comments from the forum worth visiting with regard to this proposal:

https://forum.dlang.org/post/plja2k$28r0$1@digitalmars.com https://forum.dlang.org/post/pljpnr$7g9$1@digitalmars.com

--