On Thu, Nov 8, 2018 at 3:10 AM Vijay Nayar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 25 July 2018 at 21:55:00 UTC, Manu wrote:
> > On Wed, 25 Jul 2018 at 13:55, 12345swordy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >> > It's not a false equivalence fallacy: all the discussion is about IMPLICIT conversion or rvalues to lvalues.
> >> Yes it is, the issues regarding rvalue/lvalue conversion is not the same issues regarding the unsigned/signed conversion.
> >
> > I don't want to encourage this tangent, but I do want to say;
> > there's
> > no proposal of rvalue -> lvalue *conversion*.
> > The proposal is "ref accepts rvalues". There's no 'conversion'
> > anywhere in sight. That's not on the menu.
>
> I know this is kinda out of the blue, but I really like to use "in" and "out" to clarify my function interfaces.  "out" seems to imply "ref", but it also initializes the value to its .init value.
>
> Personally I don't get much mileage out of "out" assigning the ".init" value.  The same keyword though could be used to satisfy both major use cases.
>
> Maybe "ref" could accept rvalues as per the DIP, but "out ref" would not, allowing error checking for those who truly intend the argument to be used to store output (and this comes up a lot when a method needs to return multiple results).

I think it's reasonable that `out` could reject rvalues.

On Friday, 9 November 2018 at 02:25:08 UTC, Manu wrote:
> I think it's reasonable that `out` could reject rvalues.

I have a question about lifetime. Consider your example

  ref int gun(return ref int y);

The current state `ref` also means that the return value of `gun` has an address.

Using `gun` on an rvalue, it makes an invisible variable in the caller's scope.

Will

  int* p = &(gun(10));

compile and `p` be referencing the invisible variable?

On Fri, Nov 9, 2018 at 10:15 AM Q. Schroll via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Friday, 9 November 2018 at 02:25:08 UTC, Manu wrote:
> > I think it's reasonable that `out` could reject rvalues.
>
> I have a question about lifetime. Consider your example
>
>    ref int gun(return ref int y);
>
> The current state `ref` also means that the return value of `gun` has an address.
>
> Using `gun` on an rvalue, it makes an invisible variable in the caller's scope.
>
> Will
>
>    int* p = &(gun(10));
>
> compile and `p` be referencing the invisible variable?

That's not @safe, for obvious reasons.

On Fri, 09 Nov 2018 21:56:09 -0800, Manu wrote:
> That's not @safe, for obvious reasons.

I see three different ways of implementing DIP 1016, and exactly what's @safe differs in each.

The compiler can add in the temporary variable declaration at the start of the current scope, and the following would compile:

    int* gun(return ref p) { return &p; }
    void main()
    {
      // compiler adds: int __tmp = 10;
      int* p;
      // compiler converts to: p = gun(__tmp);
      p = gun(10);
    }

Or the compiler can add a new scope just for the temporary variable, entirely preventing escaping. It would be lowered to:

    int* p;
    {
      int __tmp = 10;
      p = gun(__tmp);
    }

And that wouldn't fly, obviously.

Or it could add the temporary variable just before the current statement, so you could write:

    writeln("hi");
    int* p = gun(10);

    // compiler sees:
    writeln("hi");
    int __tmp = 10;
    int* p;
    p = gun(__tmp);

But if you tried declaring the pointer first, you'd get:

    writeln("hi");
    int* p;
    p = gun(10);

    // compiler sees:
    writeln("hi");
    int* p;
    int __tmp = 10;
    p = gun(__tmp);

And -dip1000 requires the pointed-to value to come into existence before the pointer, so this doesn't work.

On Fri, Nov 9, 2018 at 11:00 PM Neia Neutuladh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> Or the compiler can add a new scope just for the temporary variable, entirely preventing escaping. It would be lowered to:
>
>     int* p;
>     {
>       int __tmp = 10;
>       p = gun(__tmp);
>     }
>
> And that wouldn't fly, obviously.

This is the proper lowering, as detailed extensively in the DIP.
This operation is invalid, it's clearly an escaping local, and the
normal compiler semantics apply; there are no special rules prescribed
to this case:

void fun() @safe
{
    int* p;
    {
        int __tmp = 10;
        p = &__tmp;
    }
}

error : cannot take address of local `__tmp` in `@safe` function `fun`