On Wednesday, 3 June 2015 at 03:57:38 UTC, bitwise wrote:
> I forgot to mention, in terms of this statement I made:
>
>> I can't remember right now what the reasoning was for 'const ref' not to take
>> rvalues in the first place. I think it was that you could escape the reference,
>> but this isn't true anymore with DIP25 right?
>
> I think someone brought this up about a weeks ago,
That was me.
> and this was Andrei's response:
>
>> Knee-jerk response: if no "return" attribute on a function it should be safeto bind rvalues to ref parameters. Of course that's impractical as a default
>> so explicit "auto ref" would be needed. -- Andrei
>
> What's impractical?

It's dangerous. If rvalues could be passed to normal ref parameter we would have a problem. Consider this:

----
struct Sprite {
    private Texture* _tex;

    this(ref Texture tex) {
        _tex = &tex;
    }
}
----

This works because we accept a valid lvalue and store a pointer to it. If the CTor would accept also rvalues, then the pointer would be invalid, since the texture was just a temporary variable. Not the best example, but I think you understand what I mean.

On Wednesday, 3 June 2015 at 07:09:09 UTC, Namespace wrote:
> On Wednesday, 3 June 2015 at 03:57:38 UTC, bitwise wrote:
>> I forgot to mention, in terms of this statement I made:
>>
>>> I can't remember right now what the reasoning was for 'const ref' not to take
>>> rvalues in the first place. I think it was that you could escape the reference,
>>> but this isn't true anymore with DIP25 right?
>>
>> I think someone brought this up about a weeks ago,
> That was me.
>> and this was Andrei's response:
>>
>>> Knee-jerk response: if no "return" attribute on a function it should be safeto bind rvalues to ref parameters. Of course that's impractical as a default
>>> so explicit "auto ref" would be needed. -- Andrei
>>
>> What's impractical?
>
> It's dangerous. If rvalues could be passed to normal ref parameter we would have a problem. Consider this:
>
> ----
> struct Sprite {
>     private Texture* _tex;
>
>     this(ref Texture tex) {
>         _tex = &tex;
>     }
> }
> ----
>
> This works because we accept a valid lvalue and store a pointer to it. If the CTor would accept also rvalues, then the pointer would be invalid, since the texture was just a temporary variable. Not the best example, but I think you understand what I mean.

This code needs to be disallowed under DIP25 (or whatever the final DIP will be), of course.

> This code needs to be disallowed under DIP25 (or whatever the final DIP will be), of course.

But should work with return ref instead.

On Tuesday, 2 June 2015 at 17:31:56 UTC, Jonathan M Davis wrote:
> On Tuesday, 2 June 2015 at 17:22:07 UTC, Marc Schütz wrote:
>> On Tuesday, 2 June 2015 at 16:02:56 UTC, Namespace wrote:
>>> Thanks to DIP 25 I think it's time to review this again. I would implement it (if no one else wants to do it), but there are still some unanswered questions:
>>>
>>> 1. Is 'auto ref' still the chosen syntax (I guess so)?
>>
>> Why not `scope ref` (or `in ref` == `const scope ref`)?
>
> Because scope isn't even properly defined. Certainly, if we were to go that route, we'd have to finish working out what the heck scope is really supposed to do and mean. And we haven't done that yet. As it stands, everyone has their own ideas about what it means and/or should mean, but all the spec says for scope parameters is that "references in the parameter cannot be escaped (e.g. assigned to a global variable)", and right now, the only thing that scope affects is delegate parameters, and I'm not sure that even that works correctly yet or is properly ironed out.
>
> So, while maybe using scope ref for this would make sense, we have a _lot_ to figure out before we can really consider that.
>

That's what makes it an ideal choice in my opinion :-) Whatever semantics we give it is by definition not a breaking change...

Besides, I do have a pretty good idea what `scope` should mean, including most of the finer details. I summarized it here:
http://wiki.dlang.org/User:Schuetzm/scope3

The lack of progress on this topic is not because no solution is known.

>>> 4. What's with this constellation:
>>>
>>> struct S { }
>>>
>>> void ene(S) { }
>>> void mene(ref S) { }
>>> void muh(auto ref S) { }
>>>
>>> should 'mene' (ref) interfere with 'muh' (auto ref)?
>>
>> If overloading on `scope` is allowed, then yes, else no.
>
> It's not currently allowed. But regardless, if the whole point of saying scope ref (or whatever attribute we picked) was to indicate that we wanted the parameter to accept both lvalues and rvalues, then it makes no sense whatsoever to overload the parameter on ref, and it would be ref underneath the hood anyway, because that's how it would have to be implemented.

There are use-cases for overloading on scope with value types, but there are other ways to achieve the same goals (see here: http://wiki.dlang.org/User:Schuetzm/scope3#scope_for_value_types_.26_overloading).

On Tuesday, 2 June 2015 at 18:06:32 UTC, Namespace wrote:
> On Tuesday, 2 June 2015 at 17:22:07 UTC, Marc Schütz wrote:
>> On Tuesday, 2 June 2015 at 16:02:56 UTC, Namespace wrote:
>>> Thanks to DIP 25 I think it's time to review this again. I would implement it (if no one else wants to do it), but there are still some unanswered questions:
>>>
>>> 1. Is 'auto ref' still the chosen syntax (I guess so)?
>>
>> Why not `scope ref` (or `in ref` == `const scope ref`)?
>
> See DIP 36

I don't see an argument against `scope ref` in DIP36, quite the opposite...

On Wednesday, 3 June 2015 at 10:07:41 UTC, Marc Schütz wrote
> I don't see an argument against `scope ref` in DIP36, quite the opposite...

I know I was one of the authors. But it was rejected.

On Wednesday, 3 June 2015 at 09:53:36 UTC, Namespace wrote:
>> This code needs to be disallowed under DIP25 (or whatever the final DIP will be), of course.
>
> But should work with return ref instead.

It can even be allowed with an extension to DIP25:

struct Sprite {
    private Texture* _tex;

    this(ref Texture tex return(this)) {
        _tex = &tex;
    }
}

`return(param)` (or e.g. `out(param)`) means that the reference can escape through `param`.

The method can't accept an rvalue ref then, of course.

On 06/03/2015 05:43 AM, bitwise wrote:
>>
>
> Why can't const ref accept rvalues?
>
> const being too restrictive doesn't seem like a real reason, because
> although its undesirable for some cases, doesn't mean it can't be useful
> in a _lot_ of other cases.

Its a real reason unless you endorse patchwork language design. This is an obvious hole. There is absolutely no valid reason to solve only part of the issue in a non-orthogonal fashion.

On 06/02/2015 11:21 PM, Andrei Alexandrescu wrote:
>>
>
> Yah, auto ref for templates is great. We only need to add auto ref for
> non-templates with the semantics "like ref, except (a) accepts rvalues
> on the caller side, (b) does not allow escaping the ref from the function".
>

What if one wants those semantics for some template function parameters?
It seems arbitrary to introduce this feature for all functions except templated ones.

On Wed, 03 Jun 2015 03:09:06 -0400, Namespace <rswhite4@gmail.com> wrote:

> On Wednesday, 3 June 2015 at 03:57:38 UTC, bitwise wrote:
>> I forgot to mention, in terms of this statement I made:
>>
>>> I can't remember right now what the reasoning was for 'const ref' not to take
>>> rvalues in the first place. I think it was that you could escape the reference,
>>> but this isn't true anymore with DIP25 right?
>>
>> I think someone brought this up about a weeks ago,
> That was me.
>> and this was Andrei's response:
>>
>>> Knee-jerk response: if no "return" attribute on a function it should be safeto bind rvalues to ref parameters. Of course that's impractical as a default
>>> so explicit "auto ref" would be needed. -- Andrei
>>
>> What's impractical?
>
> It's dangerous. If rvalues could be passed to normal ref parameter we would have a problem. Consider this:
>
> ----
> struct Sprite {
>      private Texture* _tex;
>
>      this(ref Texture tex) {
>          _tex = &tex;
>      }
> }
> ----
>
> This works because we accept a valid lvalue and store a pointer to it. If the CTor would accept also rvalues, then the pointer would be invalid, since the texture was just a temporary variable. Not the best example, but I think you understand what I mean.


Hmm.... Indeed. It seems I misunderstood DIP25. I didn't think that was allowed.

It appears that even this is allowed:

private Texture* _tex;
struct Sprite {
    this(ref Texture tex) {
        _tex = &tex;
    }
}

Is DIP25 intended to eventually prevent these examples?

Wouldn't it have made more sense for DIP25 prevent _all_ escaping, including pointers? or is that not possible?
Then, instead of 'return ref' it could be 'escape ref' or something.
Anyways, moot point I suppose.

  Bit