digitalmars.D - http://wiki.dlang.org/DIP25 has been preliminarily approved for 2.067
- Andrei Alexandrescu (4/4) Jan 16 2015 Please help us work the kinks out! Walter will be proceeding with the
- Zach the Mystic (5/9) Jan 16 2015 I'm working on an article/DIP which actually goes further than
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (6/18) Jan 17 2015 I'm very interested in that!
- Zach the Mystic (3/12) Jan 17 2015 Yup. In fact, my DIP is partly inspired the 'scope!' syntax
- Zach the Mystic (3/6) Jan 18 2015 Here it is:
- Brian Schott (6/10) Jan 16 2015 I added support to my tools a few days ago:
- Andrei Alexandrescu (3/14) Jan 16 2015 Fantastic. Walter has a pull for the parser already. Please don't forget...
- Walter Bright (2/5) Jan 16 2015 https://github.com/D-Programming-Language/dmd/pull/4298
- Steven Schveighoffer (18/21) Jan 16 2015 I was about to complain because I remember not liking that DIP, but I
- Walter Bright (5/10) Jan 16 2015 That is addressed by the DIP, it is specifically allowed that a 'return ...
- Daniel Kozak (10/14) Jan 16 2015 Some questions
- Steven Schveighoffer (9/23) Jan 16 2015 To have a more formal place to put a proposal for a major D language
- Daniel Kozak via Digitalmars-d (4/37) Jan 16 2015 Oh I see, I miss it
- Andrei Alexandrescu (11/26) Jan 16 2015 Walter and I.
- Steven Schveighoffer (6/10) Jan 16 2015 Well, it does include last modified automatically at the bottom of the
- Andrei Alexandrescu (4/15) Jan 16 2015 Then I'd say just yank it. Apparently you can with an extension:
- Steven Schveighoffer (7/23) Jan 16 2015 I figured it out, thanks in part to your link :)
- Andrei Alexandrescu (2/25) Jan 16 2015 Heh, nice insight :o). -- Andrei
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (6/31) Jan 17 2015 That's not necessarily a good change. The date should reflect
- Jacob Carlborg (6/9) Jan 17 2015 How can we do that when you're just saying things like "Time to move
- Andrei Alexandrescu (3/11) Jan 17 2015 I'm the author so I'm waiting for comments from the others, not prone to...
- Jacob Carlborg (4/6) Jan 18 2015 I'm not sure who made the proposal but Walter created the pull request.
- Andrei Alexandrescu (3/7) Jan 18 2015 Walter and I made the proposal. Could you explain exactly what your
- Walter Bright (2/10) Jan 18 2015 It's also based on Marc Schütz's earlier proposal.
- zeljkog (2/6) Jan 16 2015 Why is it restricted to @safe?
- Steven Schveighoffer (4/13) Jan 16 2015 I don't think it is, the numerous @safe tags are superfluous.
- Walter Bright (2/3) Jan 16 2015 Being a systems programming language, an escape from it may be necessary...
- bearophile (5/9) Jan 16 2015 But this DIP to have a meaning should go with a "@safe by
- Steven Schveighoffer (11/14) Jan 16 2015 So:
- Andrei Alexandrescu (3/18) Jan 16 2015 The DIP applies to @safe code only for now. Steve, could you please add
- Steven Schveighoffer (3/5) Jan 16 2015 OK, done. Please review.
- Andrei Alexandrescu (2/6) Jan 16 2015 Just what the doctor prescribed, thanks! -- Andrei
- Joseph Cassman (9/38) Jan 16 2015 Overall I like this improvement. I think the change to `return`
- Andrei Alexandrescu (2/11) Jan 16 2015 To avoid some of the code breakage. -- Andrei
- weaselcat (4/8) Jan 16 2015 I prefer the new syntax, this is a good change.
- Andrei Alexandrescu (2/12) Jan 16 2015 No, it's a gateway drug. -- Andrei
- Paolo Invernizzi (7/11) Jan 17 2015 Congratulations to all, I like it, now: It's for sure an
- Manu via Digitalmars-d (7/11) Jan 17 2015 So when handling ref-related edge cases, do we now have to handle 3
- Andrei Alexandrescu (2/5) Jan 17 2015 Yes. -- Andrei
- Walter Bright (2/7) Jan 17 2015 Or have your mixins generate templates, which will infer 'return'.
- Manu via Digitalmars-d (5/13) Jan 17 2015 *sigh*
- deadalnix (4/15) Jan 18 2015 On that ref issue, I just have to duplicate a bunch of code so it
- Meta (5/9) Jan 17 2015 It seems to me that once this DIP is implemented, it should be
- Jonathan M Davis via Digitalmars-d (20/23) Jan 17 2015 I would point out that the "Deduction" section has code that won't even
- Walter Bright (4/8) Jan 18 2015 Your last sentence explains it.
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
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 AndreiI'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
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: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.Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 AndreiI'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 17 2015
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 MysticYup. In fact, my DIP is partly inspired the 'scope!' syntax suggestion in your DIP.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
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
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 AndreiI 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
On 1/16/15 2:00 PM, Brian Schott wrote:On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote:Fantastic. Walter has a pull for the parser already. Please don't forget the feature is opt-in. -- AndreiPlease help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 AndreiI 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
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/DIP25https://github.com/D-Programming-Language/dmd/pull/4298
Jan 16 2015
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/DIP25I 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
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
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 AndreiSome 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
On 1/16/15 5:52 PM, Daniel Kozak wrote:On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote:To have a more formal place to put a proposal for a major D language improvement.Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 AndreiSome questions What is purpose of DIPs?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.comWhy 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
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:Oh I see, I miss itOn Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote:To have a more formal place to put a proposal for a major D language improvement.Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 AndreiSome questions What is purpose of DIPs?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.comThanksWhy 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
On 1/16/15 2:52 PM, Daniel Kozak wrote:On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote:To improve D :o). DIP = D Improvement Proposal.Please help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 AndreiSome questions What is purpose of DIPs?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
On 1/16/15 6:01 PM, Andrei Alexandrescu wrote:On 1/16/15 2:52 PM, Daniel Kozak wrote: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. -SteveWhy DIP says: Last Modified: 2015-01-11 but from history I see lots of changing after that date?I wish that were automated.
Jan 16 2015
On 1/16/15 4:56 PM, Steven Schveighoffer wrote:On 1/16/15 6:01 PM, Andrei Alexandrescu wrote:Then I'd say just yank it. Apparently you can with an extension: http://www.mediawiki.org/wiki/Extension:LastModified AndreiOn 1/16/15 2:52 PM, Daniel Kozak wrote: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.Why DIP says: Last Modified: 2015-01-11 but from history I see lots of changing after that date?I wish that were automated.
Jan 16 2015
On 1/16/15 8:18 PM, Andrei Alexandrescu wrote:On 1/16/15 4:56 PM, Steven Schveighoffer wrote: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 :) -SteveOn 1/16/15 6:01 PM, Andrei Alexandrescu wrote:Then I'd say just yank it. Apparently you can with an extension: http://www.mediawiki.org/wiki/Extension:LastModifiedOn 1/16/15 2:52 PM, Daniel Kozak wrote: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.Why DIP says: Last Modified: 2015-01-11 but from history I see lots of changing after that date?I wish that were automated.
Jan 16 2015
On 1/16/15 5:51 PM, Steven Schveighoffer wrote:On 1/16/15 8:18 PM, Andrei Alexandrescu wrote:Heh, nice insight :o). -- AndreiOn 1/16/15 4:56 PM, Steven Schveighoffer wrote: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 :)On 1/16/15 6:01 PM, Andrei Alexandrescu wrote:Then I'd say just yank it. Apparently you can with an extension: http://www.mediawiki.org/wiki/Extension:LastModifiedOn 1/16/15 2:52 PM, Daniel Kozak wrote: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.Why DIP says: Last Modified: 2015-01-11 but from history I see lots of changing after that date?I wish that were automated.
Jan 16 2015
On Saturday, 17 January 2015 at 01:51:25 UTC, Steven Schveighoffer wrote:On 1/16/15 8:18 PM, Andrei Alexandrescu wrote: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 1/16/15 4:56 PM, Steven Schveighoffer wrote: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).On 1/16/15 6:01 PM, Andrei Alexandrescu wrote:Then I'd say just yank it. Apparently you can with an extension: http://www.mediawiki.org/wiki/Extension:LastModifiedOn 1/16/15 2:52 PM, Daniel Kozak wrote: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.Why DIP says: Last Modified: 2015-01-11 but from history I see lots of changing after that date?I wish that were automated.
Jan 17 2015
On 2015-01-17 00:01, Andrei Alexandrescu wrote:On 1/16/15 2:52 PM, Daniel Kozak wrote: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 CarlborgP.S. I like this DIP, but I do not like way how things are done :(Please participate to improving how things are done.
Jan 17 2015
On 1/17/15 3:56 AM, Jacob Carlborg wrote:On 2015-01-17 00:01, Andrei Alexandrescu wrote:I'm the author so I'm waiting for comments from the others, not prone to commenting on my own proposal. --- AndreiOn 1/16/15 2:52 PM, Daniel Kozak wrote: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?P.S. I like this DIP, but I do not like way how things are done :(Please participate to improving how things are done.
Jan 17 2015
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. --- AndreiI'm not sure who made the proposal but Walter created the pull request. -- /Jacob Carlborg
Jan 18 2015
On 1/18/15 5:44 AM, Jacob Carlborg wrote:On 2015-01-17 18:43, Andrei Alexandrescu wrote:Walter and I made the proposal. Could you explain exactly what your problem is. -- AndreiI'm the author so I'm waiting for comments from the others, not prone to commenting on my own proposal. --- AndreiI'm not sure who made the proposal but Walter created the pull request.
Jan 18 2015
On 1/18/2015 8:34 AM, Andrei Alexandrescu wrote:On 1/18/15 5:44 AM, Jacob Carlborg wrote:It's also based on Marc Schütz's earlier proposal.On 2015-01-17 18:43, Andrei Alexandrescu wrote:Walter and I made the proposal. Could you explain exactly what your problem is.I'm the author so I'm waiting for comments from the others, not prone to commenting on my own proposal. --- AndreiI'm not sure who made the proposal but Walter created the pull request.
Jan 18 2015
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 AndreiWhy is it restricted to safe?
Jan 16 2015
On 1/16/15 6:10 PM, zeljkog wrote:On 16.01.15 22:41, Andrei Alexandrescu wrote:I don't think it is, the numerous safe tags are superfluous. Andrei/Walter should clarify this... -StevePlease help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 AndreiWhy is it restricted to safe?
Jan 16 2015
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
Walter Bright:On 1/16/2015 3:10 PM, zeljkog wrote:But this DIP to have a meaning should go with a " safe by default", I think. Bye, bearophileWhy is it restricted to safe?Being a systems programming language, an escape from it may be necessary.
Jan 16 2015
On 1/16/15 6:25 PM, Walter Bright wrote:On 1/16/2015 3:10 PM, zeljkog wrote: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." -SteveWhy is it restricted to safe?Being a systems programming language, an escape from it may be necessary.
Jan 16 2015
On 1/16/15 3:55 PM, Steven Schveighoffer wrote:On 1/16/15 6:25 PM, Walter Bright wrote:The DIP applies to safe code only for now. Steve, could you please add a clarifying section. Thanks! -- AndreiOn 1/16/2015 3:10 PM, zeljkog wrote: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." -SteveWhy is it restricted to safe?Being a systems programming language, an escape from it may be necessary.
Jan 16 2015
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! -- AndreiOK, done. Please review. -Steve
Jan 16 2015
On 1/16/15 4:24 PM, Steven Schveighoffer wrote:On 1/16/15 7:14 PM, Andrei Alexandrescu wrote:Just what the doctor prescribed, thanks! -- AndreiThe DIP applies to safe code only for now. Steve, could you please add a clarifying section. Thanks! -- AndreiOK, done. Please review.
Jan 16 2015
On Saturday, 17 January 2015 at 00:14:47 UTC, Andrei Alexandrescu wrote:On 1/16/15 3:55 PM, Steven Schveighoffer wrote: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. JosephOn 1/16/15 6:25 PM, Walter Bright wrote:The DIP applies to safe code only for now. Steve, could you please add a clarifying section. Thanks! -- AndreiOn 1/16/2015 3:10 PM, zeljkog wrote: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." -SteveWhy is it restricted to safe?Being a systems programming language, an escape from it may be necessary.
Jan 16 2015
On 1/16/15 3:10 PM, zeljkog wrote:On 16.01.15 22:41, Andrei Alexandrescu wrote:To avoid some of the code breakage. -- AndreiPlease help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 AndreiWhy is it restricted to safe?
Jan 16 2015
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 AndreiI prefer the new syntax, this is a good change. Is this DIP replacing DIP69?
Jan 16 2015
On 1/16/15 3:45 PM, weaselcat wrote:On Friday, 16 January 2015 at 21:41:25 UTC, Andrei Alexandrescu wrote:No, it's a gateway drug. -- AndreiPlease help us work the kinks out! Walter will be proceeding with the opt-in implementation for quicker pipelining. http://wiki.dlang.org/DIP25 AndreiI prefer the new syntax, this is a good change. Is this DIP replacing DIP69?
Jan 16 2015
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 AndreiCongratulations to all, I like it, now: It's for sure an appreciated step forward! yay! --- /Paolo
Jan 17 2015
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 AndreiSo 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
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
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
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:*sigh* Don't get me started on auto-ref again. We'll need some sort of traits to detect the return-ref case.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
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: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.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 18 2015
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 AndreiIt 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
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/DIP25I 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
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