www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 16 2015
next sibling parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
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.
Jan 16 2015
next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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.
Jan 17 2015
parent "Zach the Mystic" <reachzach gggmail.com> writes:
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.
Jan 17 2015
prev sibling parent "Zach the Mystic" <reachzach gggmail.com> writes:
On Friday, 16 January 2015 at 21:55:13 UTC, Zach the Mystic wrote:
 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.
Here it is: http://forum.dlang.org/thread/xjhvpmjrlwhhgeqyoipv forum.dlang.org
Jan 18 2015
prev sibling next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
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 added support to my tools a few days ago: https://github.com/Hackerpilot/libdparse/commit/fc9dacfa41c0bae258814ad64e58ffaae6b961cc Now I need to make a pull request that updates the official grammar...
Jan 16 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/16/15 2:00 PM, Brian Schott 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 added support to my tools a few days ago: https://github.com/Hackerpilot/libdparse/commit/fc9dacfa41c0bae258814ad64e58ffaae6b961cc Now I need to make a pull request that updates the official grammar...
Fantastic. Walter has a pull for the parser already. Please don't forget the feature is opt-in. -- Andrei
Jan 16 2015
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/16/2015 1:41 PM, 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
https://github.com/D-Programming-Language/dmd/pull/4298
Jan 16 2015
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/16/15 4:41 PM, 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
I was about to complain because I remember not liking that DIP, but I see you removed inout as the notation, opting for return instead. Looks good now! One thing I would note: in "Types of Result vs. Parameters", I think it should stay this way. Simple explanation is: IFTI/auto returns. We have a very similar situation with inout. Originally, I insisted that inout only was valid on a parameter if it was also designated on the return. This kind of makes sense. But it caused issues with templates, because inout could be deduced by IFTI, and then it wasn't on the return. We have now fixed the compiler so inout reduces to const if not specified on the return. I can potentially see a situation like this: auto fun(T)(return ref T x) Where the auto deduces to something that couldn't possibly match T or any piece of it. Causing this function to error just because of a type mismatch is the wrong move. -Steve
Jan 16 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/16/2015 2:13 PM, Steven Schveighoffer wrote:
 I can potentially see a situation like this:

 auto fun(T)(return ref T x)

 Where the auto deduces to something that couldn't possibly match T or any piece
 of it. Causing this function to error just because of a type mismatch is the
 wrong move.
That is addressed by the DIP, it is specifically allowed that a 'return ref' can be used even when the pointer cannot be coerced into the returned ref. This is so that the 'return ref' can refer to a container that completely owns its contents, and this ownership can thus be transferred to the output.
Jan 16 2015
prev sibling next sibling parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
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
Some questions What is purpose of DIPs? Who can approve them? How can something been preliminarily approved without any discussion? Why DIP says: Last Modified: 2015-01-11 but from history I see lots of changing after that date? P.S. I like this DIP, but I do not like way how things are done :(
Jan 16 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/16/15 5:52 PM, Daniel Kozak 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
Some questions What is purpose of DIPs?
To have a more formal place to put a proposal for a major D language improvement.
 Who can approve them?
Ultimately, Walter.
 How can something been preliminarily approved without any discussion?
Much discussion has happened on this. e.g.: http://forum.dlang.org/post/m7ns90$16t1$1 digitalmars.com http://forum.dlang.org/post/ket199$2c27$1 digitalmars.com
 Why DIP says: Last Modified: 2015-01-11
 but from history I see lots of changing after that date?
That date is manually entered. I'll fix it. -Steve
Jan 16 2015
parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Steven Schveighoffer via Digitalmars-d píše v Pá 16. 01. 2015 v 17:59
-0500:
 On 1/16/15 5:52 PM, Daniel Kozak 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
Some questions What is purpose of DIPs?
To have a more formal place to put a proposal for a major D language improvement.
 Who can approve them?
Ultimately, Walter.
 How can something been preliminarily approved without any discussion?
Much discussion has happened on this. e.g.: http://forum.dlang.org/post/m7ns90$16t1$1 digitalmars.com http://forum.dlang.org/post/ket199$2c27$1 digitalmars.com
Oh I see, I miss it
 Why DIP says: Last Modified: 2015-01-11
 but from history I see lots of changing after that date?
That date is manually entered. I'll fix it. -Steve
Thanks
Jan 16 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/16/15 2:52 PM, Daniel Kozak 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
Some questions What is purpose of DIPs?
To improve D :o). DIP = D Improvement Proposal.
 Who can approve them?
Walter and I.
 How can something been preliminarily approved without any discussion?
There's been quite a bit of it, and we listened to it - we changed "inout" to "return". This has been public for a good time and is important AND urgent while much debate has been carried on inconsequential topics. Time to move forward.
 Why DIP says: Last Modified: 2015-01-11
 but from history I see lots of changing after that date?
I wish that were automated.
 P.S. I like this DIP, but I do not like way how things are done :(
Please participate to improving how things are done. Andrei
Jan 16 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jan 16 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 16 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jan 16 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 16 2015
prev sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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.
Jan 17 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 17 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 17 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-01-17 18:43, Andrei Alexandrescu wrote:

 I'm the author so I'm waiting for comments from the others, not prone to
 commenting on my own proposal. --- Andrei
I'm not sure who made the proposal but Walter created the pull request. -- /Jacob Carlborg
Jan 18 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/18/15 5:44 AM, Jacob Carlborg wrote:
 On 2015-01-17 18:43, Andrei Alexandrescu wrote:

 I'm the author so I'm waiting for comments from the others, not prone to
 commenting on my own proposal. --- Andrei
I'm not sure who made the proposal but Walter created the pull request.
Walter and I made the proposal. Could you explain exactly what your problem is. -- Andrei
Jan 18 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/18/2015 8:34 AM, Andrei Alexandrescu wrote:
 On 1/18/15 5:44 AM, Jacob Carlborg wrote:
 On 2015-01-17 18:43, Andrei Alexandrescu wrote:

 I'm the author so I'm waiting for comments from the others, not prone to
 commenting on my own proposal. --- Andrei
I'm not sure who made the proposal but Walter created the pull request.
Walter and I made the proposal. Could you explain exactly what your problem is.
It's also based on Marc Schütz's earlier proposal.
Jan 18 2015
prev sibling next sibling parent reply zeljkog <zeljkog home.com> writes:
On 16.01.15 22:41, 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
Why is it restricted to safe?
Jan 16 2015
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/16/15 6:10 PM, zeljkog wrote:
 On 16.01.15 22:41, 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
Why is it restricted to safe?
I don't think it is, the numerous safe tags are superfluous. Andrei/Walter should clarify this... -Steve
Jan 16 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 16 2015
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 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.
But this DIP to have a meaning should go with a " safe by default", I think. Bye, bearophile
Jan 16 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jan 16 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 16 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jan 16 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 16 2015
prev sibling parent "Joseph Cassman" <jc7919 outlook.com> writes:
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
Jan 16 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/16/15 3:10 PM, zeljkog wrote:
 On 16.01.15 22:41, 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
Why is it restricted to safe?
To avoid some of the code breakage. -- Andrei
Jan 16 2015
prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
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 prefer the new syntax, this is a good change. Is this DIP replacing DIP69?
Jan 16 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/16/15 3:45 PM, weaselcat 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 prefer the new syntax, this is a good change. Is this DIP replacing DIP69?
No, it's a gateway drug. -- Andrei
Jan 16 2015
prev sibling next sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
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
Jan 17 2015
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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...
Jan 17 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 17 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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'.
Jan 17 2015
next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Jan 17 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 17 January 2015 at 21:21:05 UTC, Walter Bright 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'.
On that ref issue, I just have to duplicate a bunch of code so it can work for classes and struct alike. There is no way to make something conditionally ref.
Jan 18 2015
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
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?
Jan 17 2015
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Jan 17 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 18 2015