On 1/16/15 7:14 PM, Andrei Alexandrescu wrote:

> The DIP applies to @safe code only for now. Steve, could you please add
> a clarifying section. Thanks! -- Andrei

OK, done. Please review.

-Steve

On 1/16/15 4:24 PM, Steven Schveighoffer wrote:
> On 1/16/15 7:14 PM, Andrei Alexandrescu wrote:
>
>> The DIP applies to @safe code only for now. Steve, could you please add
>> a clarifying section. Thanks! -- Andrei
>
> OK, done. Please review.

Just what the doctor prescribed, thanks! -- Andrei

On Saturday, 17 January 2015 at 00:14:47 UTC, Andrei Alexandrescu wrote:
> On 1/16/15 3:55 PM, Steven Schveighoffer wrote:
>> On 1/16/15 6:25 PM, Walter Bright wrote:
>>> On 1/16/2015 3:10 PM, zeljkog wrote:
>>>> Why is it restricted to @safe?
>>>
>>> Being a systems programming language, an escape from it may be necessary.
>>
>> So:
>>
>> ref int foo(ref int x) { return x; }
>>
>> is OK as long as it's not marked @safe? Is this made clear in the DIP? I
>> didn't see that. In fact @safe is never mentioned except in the code
>> examples. Even in the inline text examples, it's not mentioned.
>>
>> In at least one place, it's implied that the above would not compile
>> under the DIP: "With the proposed semantics, a function is disallowed to
>> return a ref parameter of a part thereof UNLESS the parameter is also
>> annotated with return."
>>
>> -Steve
>
> The DIP applies to @safe code only for now. Steve, could you please add a clarifying section. Thanks! -- Andrei

Overall I like this improvement. I think the change to `return` is good, keeps things clear; at least I had difficulty keeping the various usages clear (didn't have time to comment in the thread). Thanks for that. Also, I realized I was unclear about it applying to safe and not unsafe code, and why. Nice clarification. Thanks.

Joseph

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.

-Steve

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

Andrei

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).

I'll update the template. No sense in updating all the other proposals, as they will then update to today :)

-Steve

On 1/16/15 5:51 PM, 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).
>
> I'll update the template. No sense in updating all the other proposals,
> as they will then update to today :)

Heh, nice insight :o). -- Andrei

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

Congratulations to all, I like it, now: It's for sure an appreciated step forward!
yay!

---
/Paolo

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?

-- 
/Jacob Carlborg

On 17 January 2015 at 07:41, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> 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

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...