On Saturday, 17 January 2015 at 01:51:25 UTC, Steven Schveighoffer wrote:
> On 1/16/15 8:18 PM, Andrei Alexandrescu wrote:
>> On 1/16/15 4:56 PM, Steven Schveighoffer wrote:
>>> On 1/16/15 6:01 PM, Andrei Alexandrescu wrote:
>>>> On 1/16/15 2:52 PM, Daniel Kozak wrote:
>>>>> Why DIP says: Last Modified: 2015-01-11
>>>>> but from history I see lots of changing after that date?
>>>>
>>>> I wish that were automated.
>>>>
>>>
>>> Well, it does include last modified automatically at the bottom of the
>>> page. Is it worth keeping that manual entry?
>>>
>>> I tried to see if there was a way to reference that, but it's not
>>> possible from what I can tell.
>>
>> Then I'd say just yank it. Apparently you can with an extension:
>> http://www.mediawiki.org/wiki/Extension:LastModified
>
> I figured it out, thanks in part to your link :)
>
> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY}}
>
> They HAVE to be capitalized (that took me a while to figure out).

That's not necessarily a good change. The date should reflect only when the actual content changes, but not e.g. when someone adds a category, and probably neither for small changes like a fixed typo.

On Friday, 16 January 2015 at 21:55:13 UTC, Zach the Mystic wrote:
> On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote:
>> Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining.
>>
>> http://wiki.dlang.org/DIP25
>>
>>
>> Andrei
>
> I'm working on an article/DIP which actually goes further than the new DIP25, but is nonetheless completely compatible with it. I'll have the article in a day or two.

I'm very interested in that!

I think the `return` notation is a good idea, and can maybe be reused in a more complete `scope` proposal. A downside is that it only applies to the return value, but not to other `out` and `ref` parameters. But the `!` syntax can work here, too.

On 1/17/15 3:56 AM, Jacob Carlborg wrote:
> On 2015-01-17 00:01, Andrei Alexandrescu wrote:
>> On 1/16/15 2:52 PM, Daniel Kozak wrote:
>>> P.S. I like this DIP, but I do not like way how things are done :(
>>
>> Please participate to improving how things are done.
>
> How can we do that when you're just saying things like "Time to move
> forward", "it's a judgement call", "lets do it" and then just merges
> Walter's pull requests?

I'm the author so I'm waiting for comments from the others, not prone to commenting on my own proposal. --- Andrei

On 1/17/15 4:40 AM, Manu via Digitalmars-d wrote:
> I guess we'll need
> another annoying __traits or something so I can pipe that information
> into my mixins that deal with ref mess...

Yes. -- Andrei

On Saturday, 17 January 2015 at 17:08:42 UTC, Marc Schütz wrote:
> On Friday, 16 January 2015 at 21:55:13 UTC, Zach the Mystic
>> I'm working on an article/DIP which actually goes further than the new DIP25, but is nonetheless completely compatible with it. I'll have the article in a day or two.
>
> I'm very interested in that!
>
> I think the `return` notation is a good idea, and can maybe be reused in a more complete `scope` proposal. A downside is that it only applies to the return value, but not to other `out` and `ref` parameters. But the `!` syntax can work here, too.

Yup. In fact, my DIP is partly inspired the 'scope!' syntax suggestion in your DIP.

On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote:
> Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining.
>
> http://wiki.dlang.org/DIP25
>
>
> Andrei

It seems to me that once this DIP is implemented, it should be safe to allow taking an rvalue by reference in safe code as long as it is not annotated with `return`. Is this correct?

On 1/17/2015 4:40 AM, Manu via Digitalmars-d wrote:
> So when handling ref-related edge cases, do we now have to handle 3
> cases? not-ref, ref, and return-ref right?
> How do I know if some argument is return-ref? I guess we'll need
> another annoying __traits or something so I can pipe that information
> into my mixins that deal with ref mess...


Or have your mixins generate templates, which will infer 'return'.

On 18 January 2015 at 07:20, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 1/17/2015 4:40 AM, Manu via Digitalmars-d wrote:
>>
>> So when handling ref-related edge cases, do we now have to handle 3
>> cases? not-ref, ref, and return-ref right?
>> How do I know if some argument is return-ref? I guess we'll need
>> another annoying __traits or something so I can pipe that information
>> into my mixins that deal with ref mess...
>
>
>
> Or have your mixins generate templates, which will infer 'return'.

*sigh*
Don't get me started on auto-ref again.

We'll need some sort of traits to detect the return-ref case.

On Friday, January 16, 2015 13:41:24 Andrei Alexandrescu via Digitalmars-d wrote:
> Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining.
>
> http://wiki.dlang.org/DIP25

I would point out that the "Deduction" section has code that won't even compile, because it uses auto ref on a non-templated function:

auto ref T identity(auto ref T) {
    return x; // correct, no need for return
}

I assume that that should be something more like

auto ref T identity(T)(auto ref T) {
    return x; // correct, no need for return
}

Or am I misunderstanding the intent of the example? I can certainly fix the page myself, but I don't want to change it in an incorrect manner, and it's not my DIP.

In any case, while I haven't been as active on the newsgroup lately as I'd like and missed all of the previous discussions on this, the DIP doesn't seem like a bad solution. I am a bit surprised though that you agreed to it given that in previous discussions you seemed opposed to adding any more attributes for parameters. It does make for a fairly straightforward solution though.

- Jonathan M Davis

On 1/17/2015 7:38 PM, Jonathan M Davis via Digitalmars-d wrote:
> I am a bit surprised though that you agreed to it
> given that in previous discussions you seemed opposed to adding any more
> attributes for parameters. It does make for a fairly straightforward
> solution though.

Your last sentence explains it.

The 'return ref' with deduction also appears to cause the fewest changes to existing code.