digitalmars.D - I close BIP27. I won't be pursuing BIPs anymore
- deadalnix (18/18) Oct 16 2016 Long story short, it si clearly a waste of time. Qualifying the
- Nick Sabalausky (5/25) Oct 16 2016 It's not just DIPs, that pretty much fits my experience with
- Dicebot (22/34) Oct 16 2016 Listen, I understand you are not interested in spending loads of
- deadalnix (4/7) Oct 16 2016 I spent fuck 4;5 years on that thing. Don't come at me saying I'm
- Dicebot (27/36) Oct 20 2016 protected-headers="v1"
- Jacob Carlborg (10/14) Oct 16 2016 Well, the designed of the DIP process if flawed. It's basically
- Walter Bright (2/4) Oct 16 2016 What are you referring to?
- Andrei Alexandrescu (16/30) Oct 16 2016 What steps do you think we could take to improve it? Since Dicebot took
- Andrei Alexandrescu (4/6) Oct 17 2016 Copypasta error, I meant
- David Soria Parra (18/33) Oct 17 2016 Looking at other languages that have similar process. Python's
- Andrei Alexandrescu (11/26) Oct 17 2016 Thanks, David. Hope you're doing well! I was curious about one thing -
- David Soria Parra (18/28) Oct 17 2016 PEPs (sorry I totally misspelled that before) have a editors who
- Dicebot (27/56) Oct 20 2016 protected-headers="v1"
- Walter Bright (20/36) Oct 16 2016 The wiki DIP27 is here:
- Andrei Alexandrescu (47/64) Oct 16 2016 I understand your frustration and please bear with us while we're
- Joakim (14/19) Oct 17 2016 I must say, I finally read this DIP after Amaury protested and
- Walter Bright (4/8) Oct 17 2016 That process is what Mihails is in charge of. It's a difficult and thank...
- Joakim (21/33) Oct 17 2016 I know of the new DIP process and that Mihails is running it:
- Steven Schveighoffer (31/58) Oct 17 2016 TBH, I haven't paid much attention to DIPs. The one I did comment on is
- Joakim (10/14) Oct 17 2016 Also, consider the creator of C++'s recent 0/3 track record of
- Jonathan M Davis via Digitalmars-d (8/16) Oct 17 2016 Yeah. The DIP process hasn't worked very well overall, and many of the
- ZombineDev (2/20) Oct 17 2016 https://github.com/dlang/DIPs/pull/16
- Walter Bright (2/3) Oct 17 2016 Thanks. I hadn't seen it earlier because I had neglected to look in the ...
- Manu via Digitalmars-d (17/56) Oct 17 2016 You mean like that time I spent at least 2 years fighting for
- Walter Bright (6/21) Oct 17 2016 You've gotten user defined attributes in the language (and very
- Manu via Digitalmars-d (24/48) Oct 18 2016 These are practically uncontroversial though. Things like final and scop...
- Shachar Shemesh (28/33) Oct 19 2016 I take issue with that statement. Not with Manu being a positive
- Namespace (4/9) Oct 17 2016 I recently wrote a PR for p0nce D idioms, which shows how you can
- ketmar (3/12) Oct 18 2016 there is a huge difference between "i can hack around it" and "i
- Namespace (5/18) Oct 18 2016 True. ;) It's like the static-array-without-length-and-gc hack.
- Jonathan M Davis via Digitalmars-d (12/31) Oct 18 2016 Andrei decided ages ago that he didn't think that having const ref take
- Andrei Alexandrescu (6/8) Oct 18 2016 Please misquote appropriately :o). I said binding rvalues to const ref
- Jonathan M Davis via Digitalmars-d (5/13) Oct 18 2016 LOL. Sorry, I got the basic idea right but not the specifics. Thanks for...
- Manu via Digitalmars-d (6/15) Oct 18 2016 Really? Can you show how allowing passing rvalues as const T& lead to T&...
- ag0aep6g (11/17) Oct 18 2016 It would be great if we had detailed rationale articles for these
- Jonathan M Davis via Digitalmars-d (14/17) Oct 18 2016 He's explained it several times, but I confess that I've never really
- Atila Neves (33/50) Oct 18 2016 I think I get it; I'm just not sure given the comments that pop
- Andrei Alexandrescu (2/7) Oct 18 2016 That's right, thanks Atila. -- Andreu
- Jacob (15/28) Oct 18 2016 Is that really the only reason they aren't being allowed?
- Jacob (22/35) Oct 18 2016 Actually thinking it over some more, you would be able to
- Manu via Digitalmars-d (5/16) Oct 18 2016 This is obvious though, lval calls the first, rval calls the second. Sur...
- Andrei Alexandrescu (37/52) Oct 19 2016 You're missing context. The conversation went like this:
- Jonathan M Davis via Digitalmars-d (6/14) Oct 19 2016 The other big problem is that D's const is so much more restrictive than
- Andrei Alexandrescu (3/17) Oct 19 2016 That's why if we allow binding rvalues to references, we'd allow it
- Jonathan M Davis via Digitalmars-d (6/26) Oct 19 2016 Which then causes the problem that it becomes much less clear whether re...
- Namespace (5/10) Oct 19 2016 As long as it would be marked with scope (or some similar
- Jonathan M Davis via Digitalmars-d (31/42) Oct 19 2016 That's an orthogonal issue. My point is that normally, a parameter is a ...
- Namespace (37/73) Oct 19 2016 Ok, I understand what you mean, but as long as the argument
- Manu via Digitalmars-d (9/18) Oct 19 2016 Right, I was arguing this for years. Using 'scope' to make the concept
- Walter Bright (7/12) Oct 19 2016 C++ has had two goes at rvalue references. Any serious proposal for that...
- Manu via Digitalmars-d (7/23) Oct 19 2016 We're not talking about rvalue references...? I'm not sure where this
- Andrei Alexandrescu (3/4) Oct 19 2016 I'd be willing to shepherd a DIP if a couple of people want to get
- Manu via Digitalmars-d (6/21) Oct 19 2016 I've never seen a piece of code in C++ that receives const& that isn't
- bachmeier (5/7) Oct 18 2016 We do, on the wiki:
- Walter Bright (2/8) Oct 18 2016 http://wiki.dlang.org/Language_design_discussions#rvalue_references
- Timon Gehr (7/20) Oct 18 2016 It wouldn't even be the same thing if it was allowed. D const is not C++...
- Marco Leise (29/32) Oct 18 2016 For me using const ref vs. const is typically entirely a
- Timon Gehr (9/39) Oct 19 2016 Yes, the lack of rvalue references can be annoying but 'const' should be...
- Marco Leise (5/14) Oct 19 2016 Ok, got ya now!
- Walter Bright (8/10) Oct 18 2016 That's what FAQs are for, and if someone wants to collect Andrei's posts...
- Namespace (4/40) Oct 18 2016 Yep. Therefore my little hack. It works and it isn't such a big
- Manu via Digitalmars-d (12/41) Oct 18 2016 Don't misunderstand, at no point I'm aware has anyone ever talked about
- Ethan Watson (10/17) Oct 19 2016 Probably worth pointing out that we laid it out exactly like this
- Manu via Digitalmars-d (8/30) Oct 19 2016 Huh? Not even.
- Ethan Watson (11/20) Oct 19 2016 Well, it could very well have been the specifics as we laid it
- Walter Bright (5/24) Oct 19 2016 void f(ref Vector v);
- Walter Bright (4/4) Oct 19 2016 Better:
- Ethan Watson (38/42) Oct 20 2016 Suitable enough for simple functions. But beyond that becomes
- Namespace (9/21) Oct 20 2016 ----
- Andrei Alexandrescu (35/44) Oct 20 2016 I agree this workaround has a combinatorial problem.
- Walter Bright (4/8) Oct 20 2016 Yes, Ethan made a good point I hadn't thought of. And any DIP on the mat...
- Andrei Alexandrescu (4/14) Oct 20 2016 The combinatorial explosion was one core motivation for C++ rvalue
- Walter Bright (9/12) Oct 20 2016 "However, as the number of free parameters grows (as in bind and functio...
- Manu via Digitalmars-d (3/13) Oct 20 2016 Shoot me! ;)
- Ethan Watson (8/10) Oct 21 2016 I think all the information in this thread and the "Binding
- Walter Bright (2/4) Oct 21 2016 Great!
- Andrei Alexandrescu (9/14) Oct 21 2016 I, too, will look forward to that. If we get it right, we'll have a
- Timon Gehr (2/10) Oct 21 2016 Nice! Make sure it is orthogonal to const. :)
- Andrei Alexandrescu (2/14) Oct 21 2016 It would be great if you participated. Such a DIP needs you. -- Andrei
- Timon Gehr (3/18) Oct 22 2016 I'm ready to participate (but I can't invest too much time at the
- Jonathan M Davis via Digitalmars-d (4/6) Oct 22 2016 That would certainly be my preference - at least out of what's been
- bitwise (14/21) Oct 22 2016 With move semantics in mind, I'm wondering if there may be a
- bitwise (2/12) Oct 28 2016 Any news on this?
- bitwise (3/17) Oct 29 2016 Hmm. Why did I expect this?
- Andrei Alexandrescu (10/29) Oct 19 2016 "Because you're trying to write C++ in D." :o)
- Guillaume Piolat (4/13) Oct 19 2016 Just wanted to add that I still don't know (I'm lazy) what "auto
- Namespace (23/37) Oct 19 2016 For each auto ref argument the compiler will lazily generate 2^N
- Guillaume Piolat (2/3) Oct 19 2016 Thanks. Failed to find the related bit in the spec.
- bitwise (3/4) Oct 17 2016 FWIW ;)
- Jonathan M Davis via Digitalmars-d (23/47) Oct 19 2016 The transitivity of const shoot stuff in the foot pretty thoroughly in a
- Nicholas Wilson (4/30) Oct 20 2016 Is it legal to `.save` a const range, and then use it (provided
- ag0aep6g (2/4) Oct 20 2016 Sure, if it doesn't involve a cast, i.e. if save is const.
- Jonathan M Davis via Digitalmars-d (24/44) Oct 21 2016 Not really. isForwardRange requires that save return _exactly_ the same ...
Long story short, it si clearly a waste of time. Qualifying the process would be an understatement. Some specifically DIP27 has been written in Feb 2913, following various discussion at that time. I pushed it at the time. I moved it to the new git DIP repository. Got mostly irrelevant feedback (Hi Martin) and more generaly the loop time is measured in month. I'm doing this on my free time. I have other things to do. The DIP process is beyond broken. It essentially goes as : - If you are Andrei or Walter, then your DIP is just a formality. No matter how bad it is, it is in (Hi DIP25, inout turned out so great for type qualifier we clearly need that for lifetime). - If anybody else does it, you have no idea what you are getting into. You'll be still there in 5 years with no end in sight. I've been a sucker for long enough. I'm not playing anymore and I'd suggest to anyone playing to stop. I've probably be playing longer than pretty much anyone here. Trust the bitter old man, he knows.
Oct 16 2016
On Sunday, 16 October 2016 at 22:17:15 UTC, deadalnix wrote:Long story short, it si clearly a waste of time. Qualifying the process would be an understatement. Some specifically DIP27 has been written in Feb 2913, following various discussion at that time. I pushed it at the time. I moved it to the new git DIP repository. Got mostly irrelevant feedback (Hi Martin) and more generaly the loop time is measured in month. I'm doing this on my free time. I have other things to do. The DIP process is beyond broken. It essentially goes as : - If you are Andrei or Walter, then your DIP is just a formality. No matter how bad it is, it is in (Hi DIP25, inout turned out so great for type qualifier we clearly need that for lifetime). - If anybody else does it, you have no idea what you are getting into. You'll be still there in 5 years with no end in sight. I've been a sucker for long enough. I'm not playing anymore and I'd suggest to anyone playing to stop. I've probably be playing longer than pretty much anyone here. Trust the bitter old man, he knows.It's not just DIPs, that pretty much fits my experience with dmd/phobos PRs, too. The only feedback is trivial nitpicking, and then you spend a year or so babysitting an endless stream of rebases just for it to keep getting ignored.
Oct 16 2016
Listen, I understand you are not interested in spending loads of time on boring polishing of formalities. We all do this in our spare time so that is to be expected. But what you say here only shows that process is working as intended - and that it is not suitable for you. Quote from readme: "Be prepared for a lot of work. There are always many ideas proposed but far fewer developers commited to pursuing the idea to the final stages of evaluation. The DIP system is not for submitting undeveloped ideas, it is a process for formal approval of language changes". There isn't any lack of ideas in D community. Those don't hold much value on its own. What is needed is commitment and stubbornness, and DIP system, among other things, helps to not pay attention to those who are unlikely to pursue their idea to an end. On Sunday, 16 October 2016 at 22:17:15 UTC, deadalnix wrote:The DIP process is beyond broken. It essentially goes as : - If you are Andrei or Walter, then your DIP is just a formality. No matter how bad it is, it is in (Hi DIP25, inout turned out so great for type qualifier we clearly need that for lifetime).This is explicitly mentioned in README. Like it or not, but this is reality we have to live with and there is no point in pretending otherwise. Walter won't change and you can either try to make best of the status quo or move on to other things.- If anybody else does it, you have no idea what you are getting into. You'll be still there in 5 years with no end in sight. I've been a sucker for long enough. I'm not playing anymore and I'd suggest to anyone playing to stop. I've probably be playing longer than pretty much anyone here. Trust the bitter old man, he knows... and trying to convince others that your specific choice is "correct" is a shitty move.
Oct 16 2016
On Monday, 17 October 2016 at 02:08:44 UTC, Dicebot wrote:Listen, I understand you are not interested in spending loads of time on boring polishing of formalities. We all do this in our spare time so that is to be expected.I spent fuck 4;5 years on that thing. Don't come at me saying I'm not interested in polishing it. I'm not interested in wasting my time. That's entirely different.
Oct 16 2016
protected-headers="v1" From: Dicebot <public dicebot.lv> Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D Subject: Re: I close BIP27. I won't be pursuing BIPs anymore References: <hlckdmbpdlbjldcfwovj forum.dlang.org> <wwrysosdvpfijqlnhyuk forum.dlang.org> <occkwwihqvmvxdunhsua forum.dlang.org> In-Reply-To: <occkwwihqvmvxdunhsua forum.dlang.org> --WQxWflBkRQNkQqGsCAejiafu0AjdBXdlf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/17/2016 05:44 AM, deadalnix wrote:On Monday, 17 October 2016 at 02:08:44 UTC, Dicebot wrote:You did a rather terrible job if that DIP document was a result of 4.5 year effort. And that is the most polite thing I can say about such statement. Let's make it clear - https://github.com/dlang/DIPs/pull/16 featured a great idea and that was the ONLY positive bit about it. Structure and clarity of explanations are plain terrible. It looks more like throwing in the proposal with "now you go figure it out" attitude than a formal document. You never took requests to make it more clear to the heart, making only trivial tweaks. Clear signs of how DIP is lacking in clarity (the very irrelevant comments and long pause times) are now interpreted as process issue, but in fact those are your personal issue as DIP author. If you think those demands are not acceptable - new process was not designed for you and I am happy I have not wasted more of my time trying to get it into shape. --WQxWflBkRQNkQqGsCAejiafu0AjdBXdlf--Listen, I understand you are not interested in spending loads of time on boring polishing of formalities. We all do this in our spare time so that is to be expected.=20 I spent fuck 4;5 years on that thing. Don't come at me saying I'm not interested in polishing it. I'm not interested in wasting my time. That's entirely different.
Oct 20 2016
On 2016-10-17 04:08, Dicebot wrote:Listen, I understand you are not interested in spending loads of time on boring polishing of formalities. We all do this in our spare time so that is to be expected. But what you say here only shows that process is working as intendedWell, the designed of the DIP process if flawed. It's basically impossible to get something through the process unless you're Andrei or Walter. Yes, I know there's been approved DIP's but that was long time ago, when the process was very loosely defined. If you're Walter or Andrei it's more of an FYI. Most likely Andrei already merged Walter's PR for DMD for this DIP, three weeks ago after being open for two hours. -- /Jacob Carlborg
Oct 16 2016
On 10/16/2016 11:39 PM, Jacob Carlborg wrote:Most likely Andrei already merged Walter's PR for DMD for this DIP, three weeks ago after being open for two hours.What are you referring to?
Oct 16 2016
On 10/17/2016 02:39 AM, Jacob Carlborg wrote:On 2016-10-17 04:08, Dicebot wrote:What steps do you think we could take to improve it? Since Dicebot took the reins things are showing real promise. I'm sure he'd be interested in taking suggestions.Listen, I understand you are not interested in spending loads of time on boring polishing of formalities. We all do this in our spare time so that is to be expected. But what you say here only shows that process is working as intendedWell, the designed of the DIP process if flawed.It's basically impossible to get something through the process unless you're Andrei or Walter. Yes, I know there's been approved DIP's but that was long time ago, when the process was very loosely defined.Sadly the process is still not super rigorous, but as I said we're working on it. Could you please mention a few DIPs that have merit and have been unjustly rejected?If you're Walter or Andrei it's more of an FYI. Most likely Andrei already merged Walter's PR for DMD for this DIP, three weeks ago after being open for two hours.Looking at https://wiki.dlang.org/?title=DIP27&action=history, I'm seeing 10 approved DIPs. Their respective authors are: Michel Fortin and Jacob Carlborg, Alex Rønne Petersen, Dicebot and Martin Nowak, Walter Bright and Andrei Alexandrescu, Jonathan M Davis, Walter Bright (4), and David Soria Parra and Martin Nowak. Would you not expect that the creator of the language has a good presence in new work on the language? Andrei
Oct 16 2016
On 10/17/2016 02:58 AM, Andrei Alexandrescu wrote:Looking at https://wiki.dlang.org/?title=DIP27&action=history, I'm seeing 10 approved DIPs.Copypasta error, I meant https://github.com/dlang/DIPs/blob/master/DIPs/archive/README.md - thanks Timon for the correction. -- Andrei
Oct 17 2016
On Monday, 17 October 2016 at 06:58:59 UTC, Andrei Alexandrescu wrote:On 10/17/2016 02:39 AM, Jacob Carlborg wrote:Looking at other languages that have similar process. Python's PIPs are probably the closest to DIP. Two observations: 1. Python as clean tooling around PIPs. We should render PIPs from the dlang/DIP nicely at dip.dlang.org (My understanding that repository is now favored over wiki entries). 2. Python DIPs are Guido's main focus of work. Maybe we can write a bot mailing current in-process DIPs on a weekly basis to the mailinglist as digest to remind Walter, Andrei and others to reviewed. The list should ordered by last comment/review on it. I am not 100% aware of all the edge cases of the process and have a terrible track record of implementing things I say i will implement, but I can give such a mailing bot a try, by scaping dlang/DIP. 3. It would be great to be clear if the people who can accept a DIP reviewed it and what the current suggested improvements are so we can make constant head-way.On 2016-10-17 04:08, Dicebot wrote:What steps do you think we could take to improve it? Since Dicebot took the reins things are showing real promise. I'm sure he'd be interested in taking suggestions.Listen, I understand you are not interested in spending loads of time on boring polishing of formalities. We all do this in our spare time so that is to be expected. But what you say here only shows that process is working as intendedWell, the designed of the DIP process if flawed.
Oct 17 2016
On 10/17/2016 01:44 PM, David Soria Parra wrote:Looking at other languages that have similar process. Python's PIPs are probably the closest to DIP. Two observations: 1. Python as clean tooling around PIPs. We should render PIPs from the dlang/DIP nicely at dip.dlang.org (My understanding that repository is now favored over wiki entries). 2. Python DIPs are Guido's main focus of work. Maybe we can write a bot mailing current in-process DIPs on a weekly basis to the mailinglist as digest to remind Walter, Andrei and others to reviewed. The list should ordered by last comment/review on it. I am not 100% aware of all the edge cases of the process and have a terrible track record of implementing things I say i will implement, but I can give such a mailing bot a try, by scaping dlang/DIP. 3. It would be great to be clear if the people who can accept a DIP reviewed it and what the current suggested improvements are so we can make constant head-way.Thanks, David. Hope you're doing well! I was curious about one thing - is there some scrutiny going into the PIPs before Guido reviews them? Right now we seem to have a scalability issue; some of the DIPs we have seem to be no more than a couple of hours of work from the submitters. Writing a good review for a submission that needs a lot of improvement is in many ways more difficult than reviewing a well-argued DIP. I was therefore wondering - given Python's popularity - whether there is some filtering of PIPs prior to them being reviewed by Guido. Thanks, Andrei
Oct 17 2016
On Monday, 17 October 2016 at 21:52:32 UTC, Andrei Alexandrescu wrote:Thanks, David. Hope you're doing well! I was curious about one thing - is there some scrutiny going into the PIPs before Guido reviews them? Right now we seem to have a scalability issue; some of the DIPs we have seem to be no more than a couple of hours of work from the submitters. Writing a good review for a submission that needs a lot of improvement is in many ways more difficult than reviewing a well-argued DIP. I was therefore wondering - given Python's popularity - whether there is some filtering of PIPs prior to them being reviewed by Guido.PEPs (sorry I totally misspelled that before) have a editors who are responsible for scrutinizing the PEP before and as far as I understand are the ones who can request review from the BDFL (Guido), who either takes the final decision or delegates it (e.g. in cases were someone is better suited in the area to make the call). Editors are trusted core committers that are sponsoring an improvement. The process is outline in great detail at https://www.python.org/dev/peps/pep-0001/#pep-workflow and I recommend reading it. Maybe we get some good ideas on how to create a process that is scalable and results in the high quality standards we have but are more suited towards the smaller community we are. We should start small and see how we find something that Walter, you and contributors feel good about and improve from there: might suit our needs.
Oct 17 2016
protected-headers="v1" From: Dicebot <public dicebot.lv> Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D Subject: Re: I close DIP27. I won't be pursuing DIPs anymore References: <hlckdmbpdlbjldcfwovj forum.dlang.org> <wwrysosdvpfijqlnhyuk forum.dlang.org> <nu1rnn$k0g$1 digitalmars.com> <nu1srj$ldo$1 digitalmars.com> <rhlfgtmyumuhulzuejmy forum.dlang.org> <nu3h70$6uj$1 digitalmars.com> <vdagyqlwjczydqwnmous forum.dlang.org> In-Reply-To: <vdagyqlwjczydqwnmous forum.dlang.org> --i4GAx80na6ioQBkMlWT0u9q0nhi8iu3GW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/18/2016 02:40 AM, David Soria Parra wrote:On Monday, 17 October 2016 at 21:52:32 UTC, Andrei Alexandrescu wrote:Thanks, David. Hope you're doing well! I was curious about one thing -=is there some scrutiny going into the PIPs before Guido reviews them? Right now we seem to have a scalability issue; some of the DIPs we have seem to be no more than a couple of hours of work from the submitters. Writing a good review for a submission that needs a lot of=improvement is in many ways more difficult than reviewing a well-argued DIP. I was therefore wondering - given Python's popularity - whether there is some filtering of PIPs prior to them being reviewed by Guido.=20 PEPs (sorry I totally misspelled that before) have a editors who are responsible for scrutinizing the PEP before and as far as I understand are the ones who can request review from the BDFL (Guido), who either takes the final decision or delegates it (e.g. in cases were someone is=better suited in the area to make the call). Editors are trusted core committers that are sponsoring an improvement. =20 The process is outline in great detail at https://www.python.org/dev/peps/pep-0001/#pep-workflow and I recommend reading it. Maybe we get some good ideas on how to create a process tha=tis scalable and results in the high quality standards we have but are more suited towards the smaller community we are. =20 We should start small and see how we find something that Walter, you an=dcontributors feel good about and improve from there: =20 might suit our needs.But this is pretty much the process we have right now! Differences I can see: - currently I am the only person acting as a preliminary "editor" - I don't hold right to reject anything, only to request more information/improvements - it features decision delegates to someone else but BDFL is certain case= s - transition between various stages is more formally defined I doubt anyone complaining about existing DIP process would have a slightest chance to get a PEP of similar quality and style accepted as a draft. --i4GAx80na6ioQBkMlWT0u9q0nhi8iu3GW--
Oct 20 2016
On 10/16/2016 3:17 PM, deadalnix wrote:Long story short, it si clearly a waste of time. Qualifying the process would be an understatement. Some specifically DIP27 has been written in Feb 2913, following various discussion at that time. I pushed it at the time. I moved it to the new git DIP repository. Got mostly irrelevant feedback (Hi Martin) and more generaly the loop time is measured in month.The wiki DIP27 is here: https://wiki.dlang.org/DIP27 listed as a draft, last change Sep 2014. I don't see it in the new DIP repository: https://github.com/dlang/DIPs either submitted, approved, or in a PR.I'm doing this on my free time. I have other things to do. The DIP process is beyond broken. It essentially goes as : - If you are Andrei or Walter, then your DIP is just a formality. No matter how bad it is, it is in (Hi DIP25, inout turned out so great for type qualifier we clearly need that for lifetime). - If anybody else does it, you have no idea what you are getting into. You'll be still there in 5 years with no end in sight.Here's the list of approved DIPs. (It's a short list.) https://github.com/dlang/DIPs/blob/master/DIPs/archive/README.mdI've been a sucker for long enough. I'm not playing anymore and I'd suggest to anyone playing to stop. I've probably be playing longer than pretty much anyone here. Trust the bitter old man, he knows.I know it's hard to get any language changes approved. Arguably, it should be hard. For better or worse, it also takes those who believe in it to promote it, convince others of its value, and get behind it an push, hard. My proposals to C++ have seen 100% failure to gain any traction, so I have some basis for understanding how you feel. Ironically, after implementing them in D, they seem to have found fertile ground in C++, after being championed by others. My sole acknowledged contribution to C++ is the Named Return Value optimization, the rest are all unacknowledged via D :-) P.S. DIP25 had several reported bugs in it, but they have all been fixed or have open PRs to fix. None were fatal to the idea, they were just bugs. P.P.S. It may not be obvious, but you have been a positive and valued contributor to D for a long time. Thank you!
Oct 16 2016
On 10/17/2016 01:02 AM, Walter Bright wrote:On 10/16/2016 3:17 PM, deadalnix wrote:I understand your frustration and please bear with us while we're arranging the DIP process to guarantee timely response. Made a pass through https://wiki.dlang.org/DIP27. It needs serious work in order for it to be considered at the level of quality we want to foster. Here are a few suggestions that may improve its chances: * The Rationale section should present evidence and examples, instead of argumentative prose, to explain how the complexity of the language creates problems for function definitions. * Good evidence would include e.g. bugs or contorted code in existing D projects, repeated confusion in the learn forum, undue complications in the language definition, arcane compiler implementation - anything and everything that shows this is a significant problem. * There should be more concrete motivation and explanation on how exactly the language is simplified, and what the beneficial consequences of such simplification are (e.g. no more puzzling behavior, smaller/more precise specification, fewer corner cases etc). * The "Function definition and uses" section and the two following ones should explain where the proposed changes diverge from the current language. The constructive definition by means of an enum is useful, but does not offer sufficient insight to estimate the issues with the existing language definition and how the proposal addresses them. * At best, some proposed text for the language definition would be good to have, e.g. "the following paragraph in the definition: [...] shall be replaced with: [...]". * A careful editorial pass must be done to remove the numerous typos that make the document imprecise and difficult to read. Overall, as things stand, it is difficult for the reader to figure (a) what the benefits of the DIP are; (b) what the cost is in terms of code breakage (e.g. which constructs will break and how). Conveying a good understanding of the relationship between costs and benefits would greatly improve the DIP. Also, one thing to keep in mind: the way we intend DIPs going forward is ideally there would be scrutiny followed by some pick up in the community before a DIP gets submitted for formal review. The DIP has been posted in the forum on 2013-02-26 and has garnered 51 follow-ups through the next day. There were 6 more changes to the document also during those two days (https://wiki.dlang.org/?title=DIP27&action=history), most minor; most importantly the "is" expression section was added (https://wiki.dlang.org/?title=DIP27&diff=2216&oldid=2210). After that the document has been unchanged (save for one semicolon added by Rainer) for over three and a half years, during which there was no subsequent community discussion either. In an ideal world there would be some more interest and action leading up to a formal review. Thanks, AndreiLong story short, it si clearly a waste of time. Qualifying the process would be an understatement. Some specifically DIP27 has been written in Feb 2913, following various discussion at that time. I pushed it at the time. I moved it to the new git DIP repository. Got mostly irrelevant feedback (Hi Martin) and more generaly the loop time is measured in month.The wiki DIP27 is here: https://wiki.dlang.org/DIP27 listed as a draft, last change Sep 2014. I don't see it in the new DIP repository: https://github.com/dlang/DIPs either submitted, approved, or in a PR.
Oct 16 2016
On Monday, 17 October 2016 at 06:43:21 UTC, Andrei Alexandrescu wrote:On 10/17/2016 01:02 AM, Walter Bright wrote:I must say, I finally read this DIP after Amaury protested and had pretty much exactly this response, though I didn't check to see how often the DIP had been edited or worked on. I don't know enough to comment on the merit of the underlying idea, but the proposal needed work. I hope we can set up some kind of DIP review process where Mihails and other well-known community members, like Jonathan, Timon, Steven, or Amaury himself, can whip DIPs into shape before Walter and Andrei have to spend their valuable time reviewing them. I can help a little with reviewing, though only for minor things like typos or argumentation, and will start doing so.[...]I understand your frustration and please bear with us while we're arranging the DIP process to guarantee timely response. [...]
Oct 17 2016
On 10/17/2016 12:58 AM, Joakim wrote:I hope we can set up some kind of DIP review process where Mihails and other well-known community members, like Jonathan, Timon, Steven, or Amaury himself, can whip DIPs into shape before Walter and Andrei have to spend their valuable time reviewing them.That process is what Mihails is in charge of. It's a difficult and thankless job, as it attracts criticism from all sides. We are lucky that Mihails has taken on the challenge. He has my full confidence and support.
Oct 17 2016
On Monday, 17 October 2016 at 08:29:27 UTC, Walter Bright wrote:On 10/17/2016 12:58 AM, Joakim wrote:I know of the new DIP process and that Mihails is running it: https://github.com/dlang/DIPs That's great, but I'm referring to the community helping Mihails more. Here are the counts for how many DIP PRs the above well-known community members commented on: Mihails: 12 https://github.com/dlang/DIPs/pulls?utf8=✓&q=is%3Apr%20dicebot Jonathan: 0 https://github.com/dlang/DIPs/pulls?utf8=✓&q=is%3Apr%20jonathan Timon: 0 https://github.com/dlang/DIPs/pulls?utf8=✓&q=is%3Apr%20timon Steven: 1 https://github.com/dlang/DIPs/pulls?utf8=✓&q=is%3Apr%20steven Amaury: 2 https://github.com/dlang/DIPs/pulls?utf8=✓&q=is%3Apr%20deadalnix This is not meant as a criticism of those people: it's merely a random sample of outspoken forum members, to show that Mihails could use some help. My own count is 0, I'll try to change that. More people from the forum who feel strongly about changes should chip in and help Mihails, that's all I'm saying.I hope we can set up some kind of DIP review process where Mihails and other well-known community members, like Jonathan, Timon, Steven, or Amaury himself, can whip DIPs into shape before Walter and Andrei have to spend their valuable time reviewing them.That process is what Mihails is in charge of. It's a difficult and thankless job, as it attracts criticism from all sides. We are lucky that Mihails has taken on the challenge. He has my full confidence and support.
Oct 17 2016
On 10/17/16 4:57 AM, Joakim wrote:On Monday, 17 October 2016 at 08:29:27 UTC, Walter Bright wrote:TBH, I haven't paid much attention to DIPs. The one I did comment on is just because it was mentioned in the newsgroup. I haven't signed up for all notifications of DIPs, so it's not something that gets to the front of my todo-list ever. I should set aside some time to go over all the DIPs to see where they stand and how I feel about them. As a response to Amaury, I think there are definitely places where you have to have tougher skin, and this is one of them. Yes, it is sometimes infuriating that people with influence or in power can sidestep a process that us peons have to follow. But this is just the way it works when one or two people are in charge of something. It works anywhere there is a "Boss", the boss just doesn't have to deal with getting boss approval. Someone has to make the hard decisions, and they can't just approve every change. I would say the better attitude to have is that you may not expect results to always go your way, and put out your best effort. If it doesn't work, that's the way it is, move on to something more interesting and/or satisfying. The sour grapes attitude isn't helpful. And really, putting "4-5" years of effort into a wiki article doesn't sound all that taxing. I respect your contributions and knowledge, and I agree with a lot of your views on D and what should be allowed in D. Let the process work out the way it is supposed to, and suggest improvements if you think there should be. IMO, reading the history of your PR, there hasn't been a categorical rejection of the idea, I don't know why you would already give up on it. If anything, your DIP really was lost in the noise of the wiki, and really this should be considered a "new" proposal, not one that is 4-5 years old. Nobody was paying much attention to the DIPs before dicebot started this process, so I'm glad things are being examined more closely. -SteveOn 10/17/2016 12:58 AM, Joakim wrote:I know of the new DIP process and that Mihails is running it: https://github.com/dlang/DIPs That's great, but I'm referring to the community helping Mihails more. Here are the counts for how many DIP PRs the above well-known community members commented on: Mihails: 12 https://github.com/dlang/DIPs/pulls?utf8=✓&q=is%3Apr%20dicebot Jonathan: 0 https://github.com/dlang/DIPs/pulls?utf8=✓&q=is%3Apr%20jonathan Timon: 0 https://github.com/dlang/DIPs/pulls?utf8=✓&q=is%3Apr%20timon Steven: 1 https://github.com/dlang/DIPs/pulls?utf8=✓&q=is%3Apr%20steven Amaury: 2 https://github.com/dlang/DIPs/pulls?utf8=✓&q=is%3Apr%20deadalnix This is not meant as a criticism of those people: it's merely a random sample of outspoken forum members, to show that Mihails could use some help. My own count is 0, I'll try to change that.I hope we can set up some kind of DIP review process where Mihails and other well-known community members, like Jonathan, Timon, Steven, or Amaury himself, can whip DIPs into shape before Walter and Andrei have to spend their valuable time reviewing them.That process is what Mihails is in charge of. It's a difficult and thankless job, as it attracts criticism from all sides. We are lucky that Mihails has taken on the challenge. He has my full confidence and support.
Oct 17 2016
On Monday, 17 October 2016 at 13:02:20 UTC, Steven Schveighoffer wrote:I would say the better attitude to have is that you may not expect results to always go your way, and put out your best effort. If it doesn't work, that's the way it is, move on to something more interesting and/or satisfying.Also, consider the creator of C++'s recent 0/3 track record of getting his proposals into C++17: http://www.cplusplus.com/forum/general/195226/#msg938814 I was surprised that even his scaled-back UFCS proposal didn't get in: https://isocpp.org/blog/2016/02/a-bit-of-background-for-the-unified-call-proposal Note the comments after the OP there: he wants full UFCS but will settle for at least one-way. I guess even that didn't get in.
Oct 17 2016
On Monday, October 17, 2016 01:29:27 Walter Bright via Digitalmars-d wrote:On 10/17/2016 12:58 AM, Joakim wrote:Yeah. The DIP process hasn't worked very well overall, and many of the complaints about it are justfied, but what Dicebot has been up to is the attempt to fix that, and while the process still needs work, it has already improved the situation considerably. So, in that respect, now is a really weird time to be complaining about how horrible the DIP process is, since something is actually being done about it right now. - Jonathan M DavisI hope we can set up some kind of DIP review process where Mihails and other well-known community members, like Jonathan, Timon, Steven, or Amaury himself, can whip DIPs into shape before Walter and Andrei have to spend their valuable time reviewing them.That process is what Mihails is in charge of. It's a difficult and thankless job, as it attracts criticism from all sides. We are lucky that Mihails has taken on the challenge. He has my full confidence and support.
Oct 17 2016
On Monday, 17 October 2016 at 05:02:52 UTC, Walter Bright wrote:On 10/16/2016 3:17 PM, deadalnix wrote:https://github.com/dlang/DIPs/pull/16Long story short, it si clearly a waste of time. Qualifying the process would be an understatement. Some specifically DIP27 has been written in Feb 2913, following various discussion at that time. I pushed it at the time. I moved it to the new git DIP repository. Got mostly irrelevant feedback (Hi Martin) and more generaly the loop time is measured in month.The wiki DIP27 is here: https://wiki.dlang.org/DIP27 listed as a draft, last change Sep 2014. I don't see it in the new DIP repository: https://github.com/dlang/DIPs either submitted, approved, or in a PR.
Oct 17 2016
On 10/17/2016 12:45 AM, ZombineDev wrote:https://github.com/dlang/DIPs/pull/16Thanks. I hadn't seen it earlier because I had neglected to look in the closed list.
Oct 17 2016
On 17 October 2016 at 15:02, Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:On 10/16/2016 3:17 PM, deadalnix wrote:You mean like that time I spent at least 2 years fighting for final-by-default, won over the entire community except for a single person who said they were indifferent (who I forget who was). Even you begrudgingly conceded (or at least appeared to), the change was implemented, reviewed, merged, and then Andrei appeared back from holiday or wherever, and got angry that it happened in his absence and said he would *never* approve such a thing, and immediately reverted the patch...? One of the most democratic experiences of my life ;) I would be involved in the 'scope' DIP, but I fear my contribution would work against my interests. I'm currently unhappy with it, but I don't really care anymore. I've lost sight of the dream ;) I just want to be able to pass an rvalue to a function that receives a const ref... that's why I came to this forum in the first place like, 7 years ago. 7 years later... still can't.Long story short, it si clearly a waste of time. Qualifying the process would be an understatement. Some specifically DIP27 has been written in Feb 2913, following various discussion at that time. I pushed it at the time. I moved it to the new git DIP repository. Got mostly irrelevant feedback (Hi Martin) and more generaly the loop time is measured in month.The wiki DIP27 is here: https://wiki.dlang.org/DIP27 listed as a draft, last change Sep 2014. I don't see it in the new DIP repository: https://github.com/dlang/DIPs either submitted, approved, or in a PR.I'm doing this on my free time. I have other things to do. The DIP process is beyond broken. It essentially goes as : - If you are Andrei or Walter, then your DIP is just a formality. No matter how bad it is, it is in (Hi DIP25, inout turned out so great for type qualifier we clearly need that for lifetime). - If anybody else does it, you have no idea what you are getting into. You'll be still there in 5 years with no end in sight.Here's the list of approved DIPs. (It's a short list.) https://github.com/dlang/DIPs/blob/master/DIPs/archive/README.mdI've been a sucker for long enough. I'm not playing anymore and I'd suggest to anyone playing to stop. I've probably be playing longer than pretty much anyone here. Trust the bitter old man, he knows.I know it's hard to get any language changes approved. Arguably, it should be hard. For better or worse, it also takes those who believe in it to promote it, convince others of its value, and get behind it an push, hard.
Oct 17 2016
On 10/17/2016 7:54 PM, Manu via Digitalmars-d wrote:You mean like that time I spent at least 2 years fighting for final-by-default, won over the entire community except for a single person who said they were indifferent (who I forget who was). Even you begrudgingly conceded (or at least appeared to), the change was implemented, reviewed, merged, and then Andrei appeared back from holiday or wherever, and got angry that it happened in his absence and said he would *never* approve such a thing, and immediately reverted the patch...? One of the most democratic experiences of my life ;) I would be involved in the 'scope' DIP, but I fear my contribution would work against my interests. I'm currently unhappy with it, but I don't really care anymore. I've lost sight of the dream ;) I just want to be able to pass an rvalue to a function that receives a const ref... that's why I came to this forum in the first place like, 7 years ago. 7 years later... still can't.You've gotten user defined attributes in the language (and very undemocratically, I might add!), Win64 support, VC++ symbolic debug info, a number of improvements to C++ class support, SIMD support, SIMD intrinsics, pragma inline, yeah, we never listen to you :-) You've been a large influence over D, and a very positive one.
Oct 17 2016
On 18 October 2016 at 14:34, Walter Bright via Digitalmars-d < digitalmars-d puremagic.com> wrote:On 10/17/2016 7:54 PM, Manu via Digitalmars-d wrote:These are practically uncontroversial though. Things like final and scope, I had to work very hard for for many years. The amount of energy I spent on that final case was like, more than I'll ever contribute again to anything. The reason I was so insulted, and generally disengaged from this community over that matter, was that I spent *years* arguing and slowly winning this community over, to a point of unanimous agreement among the interested parties involved in the discussions, and then it was done; implemented, reviewed, merged, etc... and Andrei appeared and clicked the revert button without any hesitation. He didn't need to argue his case, he just put his foot down and said "this will not happen". I think that's the point Amaury was making, and that I was generally supporting. Perhaps he's entitled to do that... that's not for me to say. But it pissed me off enough to stop contributing my energy in any substantial manner. You've been a large influence over D, and a very positive one.You mean like that time I spent at least 2 years fighting for final-by-default, won over the entire community except for a single person who said they were indifferent (who I forget who was). Even you begrudgingly conceded (or at least appeared to), the change was implemented, reviewed, merged, and then Andrei appeared back from holiday or wherever, and got angry that it happened in his absence and said he would *never* approve such a thing, and immediately reverted the patch...? One of the most democratic experiences of my life ;) I would be involved in the 'scope' DIP, but I fear my contribution would work against my interests. I'm currently unhappy with it, but I don't really care anymore. I've lost sight of the dream ;) I just want to be able to pass an rvalue to a function that receives a const ref... that's why I came to this forum in the first place like, 7 years ago. 7 years later... still can't.You've gotten user defined attributes in the language (and very undemocratically, I might add!), Win64 support, VC++ symbolic debug info, a number of improvements to C++ class support, SIMD support, SIMD intrinsics, pragma inline, yeah, we never listen to you :-)Thanks. I wish that event never happened and I still felt as enthusiastic as I have in the past. I'd really like to get this color lib through, but it feels kinda stunted... I understand the feeling that I've seen many others expressing or complaining about. I think some process could be improved to keep a sense of motion associated with peoples efforts, and it might come up less often.
Oct 18 2016
On 18/10/16 07:34, Walter Bright wrote:You've gotten user defined attributes in the language (and very undemocratically, I might add!), Win64 support, VC++ symbolic debug info, a number of improvements to C++ class support, SIMD support, SIMD intrinsics, pragma inline, yeah, we never listen to you :-) You've been a large influence over D, and a very positive one.I take issue with that statement. Not with Manu being a positive influence, of course, but with the legitimacy of telling someone what it is they should care about. Andrei is known to have done it as well (with statements such as "choose your battles and fight them well"). You cannot tell someone volunteering his time to not care about some thing. This is simply not how you create a heterogeneous community. This is also a very bad strategy. If you accept the premise that it is possible for something to be flawed, but for both you and Andrei to not understand it is so (i.e. - the premise that both you and Andrei are human with human failing), any system in which you can control what gets discussed is a system that guarantees that this flaw will never get fixed. I understand that certain topics seem to crop up again and again, and the discussions around them seem circular. There are ways to prevent that without shutting down people. For example, taking a page from one of my pet peeves, if anyone bringing up integer promotion is not dealt with "yeah, we've discussed that and it's pointless to bring it up", but instead is shown the counter examples that halted the discussion the previous time, I believe several things will happen: 1. People will feel they are listened to. The decision will seem (but, I believe, also actually be) less arbitrary. 2. People will know where to focus their attention if they wish for this to change 3. Someone may actually find a solution. You cannot argue with "this will never happen". You can argue with "this doesn't work because of X". Shachar
Oct 19 2016
On Tuesday, 18 October 2016 at 02:54:08 UTC, Manu wrote:I just want to be able to pass an rvalue to a function that receives a const ref... that's why I came to this forum in the first place like, 7 years ago. 7 years later... still can't.I recently wrote a PR for p0nce D idioms, which shows how you can do that https://github.com/p0nce/d-idioms/pull/119
Oct 17 2016
On Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:On Tuesday, 18 October 2016 at 02:54:08 UTC, Manu wrote:there is a huge difference between "i can hack around it" and "i can do it".I just want to be able to pass an rvalue to a function that receives a const ref... that's why I came to this forum in the first place like, 7 years ago. 7 years later... still can't.I recently wrote a PR for p0nce D idioms, which shows how you can do that https://github.com/p0nce/d-idioms/pull/119
Oct 18 2016
On Tuesday, 18 October 2016 at 09:50:35 UTC, ketmar wrote:On Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:True. ;) It's like the static-array-without-length-and-gc hack. You can do it with language constructs but it's inconvenient. So it's up to Walter and Andrei to decide if this inconvenience is bearable or not.On Tuesday, 18 October 2016 at 02:54:08 UTC, Manu wrote:there is a huge difference between "i can hack around it" and "i can do it".I just want to be able to pass an rvalue to a function that receives a const ref... that's why I came to this forum in the first place like, 7 years ago. 7 years later... still can't.I recently wrote a PR for p0nce D idioms, which shows how you can do that https://github.com/p0nce/d-idioms/pull/119
Oct 18 2016
On Tuesday, October 18, 2016 13:36:42 Namespace via Digitalmars-d wrote:On Tuesday, 18 October 2016 at 09:50:35 UTC, ketmar wrote:Andrei decided ages ago that he didn't think that having const ref take rvalues was a good idea and that he doesn't think that it's a big deal. I don't recall whether Walter has said much on the issue, but AFAIK, he hasn't said anything to contradict that, and Andrei has been very vocal about how rvalue references were a horrible mistake in C++ and that he doesn't want to see anything of the sort in D. auto ref parameters solve the problem on some level, and it seems that that's the closest you're going to get to getting rvalue references in the language. I think that it's pretty clear at this point that it's not very likely that anyone is going to change Andrei's mind on this one. - Jonathan M DavisOn Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:True. ;) It's like the static-array-without-length-and-gc hack. You can do it with language constructs but it's inconvenient. So it's up to Walter and Andrei to decide if this inconvenience is bearable or not.On Tuesday, 18 October 2016 at 02:54:08 UTC, Manu wrote:there is a huge difference between "i can hack around it" and "i can do it".I just want to be able to pass an rvalue to a function that receives a const ref... that's why I came to this forum in the first place like, 7 years ago. 7 years later... still can't.I recently wrote a PR for p0nce D idioms, which shows how you can do that https://github.com/p0nce/d-idioms/pull/119
Oct 18 2016
On 10/18/2016 01:51 PM, Jonathan M Davis via Digitalmars-d wrote:Andrei has been very vocal about how rvalue references were a horrible mistake in C++Please misquote appropriately :o). I said binding rvalues to const ref is the mistake that led to the rvalue references complication. That's the truth and nothing but the truth, but not the whole truth; one thing is that the rvalue references features covers additional things not caused by the const ref mistake. -- Andrei
Oct 18 2016
On Tuesday, October 18, 2016 14:07:06 Andrei Alexandrescu via Digitalmars-d wrote:On 10/18/2016 01:51 PM, Jonathan M Davis via Digitalmars-d wrote:LOL. Sorry, I got the basic idea right but not the specifics. Thanks for the clarification. - Jonathan M DavisAndrei has been very vocal about how rvalue references were a horrible mistake in C++Please misquote appropriately :o). I said binding rvalues to const ref is the mistake that led to the rvalue references complication. That's the truth and nothing but the truth, but not the whole truth; one thing is that the rvalue references features covers additional things not caused by the const ref mistake. -- Andrei
Oct 18 2016
On 19 October 2016 at 04:07, Andrei Alexandrescu via Digitalmars-d < digitalmars-d puremagic.com> wrote:On 10/18/2016 01:51 PM, Jonathan M Davis via Digitalmars-d wrote:Really? Can you show how allowing passing rvalues as const T& lead to T&&? I honestly have never heard anything about this connection, and I can't imagine how they're connected. They seem like orthogonal issues to me...? Implementing move semantics has nothing to do with passing a temporary?Andrei has been very vocal about how rvalue references were a horrible mistake in C++Please misquote appropriately :o). I said binding rvalues to const ref is the mistake that led to the rvalue references complication. That's the truth and nothing but the truth, but not the whole truth; one thing is that the rvalue references features covers additional things not caused by the const ref mistake. -- Andrei
Oct 18 2016
On 10/18/2016 07:51 PM, Jonathan M Davis via Digitalmars-d wrote:Andrei decided ages ago that he didn't think that having const ref take rvalues was a good idea and that he doesn't think that it's a big deal. I don't recall whether Walter has said much on the issue, but AFAIK, he hasn't said anything to contradict that, and Andrei has been very vocal about how rvalue references were a horrible mistake in C++ and that he doesn't want to see anything of the sort in D.It would be great if we had detailed rationale articles for these non-obvious decisions. First, so that people get a nice prepared answer for why D is different. I can't confidently spell out why D doesn't allow passing an rvalues in a const ref parameter, and I suspect that only Andrei really can. Second, so that the decision can be attacked argumentatively. Walter and Andrei have been mistaken before, just like everyone else. It wouldn't surprise me if some variation of the feature was feasible, but it's hard to even think in that direction when the reasons against it are buried and scattered around in newsgroup discussions.
Oct 18 2016
On Tuesday, October 18, 2016 20:15:18 ag0aep6g via Digitalmars-d wrote:First, so that people get a nice prepared answer for why D is different. I can't confidently spell out why D doesn't allow passing an rvalues in a const ref parameter, and I suspect that only Andrei really can.He's explained it several times, but I confess that I've never really understood the reasoning. I know C++ well but not at the level of detail that seems to be required to understand what the exact problem is. Though as much as folks like passing rvalues to const ref in C++, isn't that generally considered to be bad practice now with C++11/14, because it doesn't play nicely with move constructors? Or at least, there are many cases where you would have used const ref previously that now you shouldn't, because it forces a copy for lvalues in some cases, whereas just passing by value would allow a move to be made? If that's the case, I'm not sure that the fact that we don't allow const ref to take rvalues is as big a deal as it would first seem to a C++98 programmer (though it's obviously still somewhat limiting). - Jonathan M Davis
Oct 18 2016
On Tuesday, 18 October 2016 at 18:33:46 UTC, Jonathan M Davis wrote:On Tuesday, October 18, 2016 20:15:18 ag0aep6g via Digitalmars-d wrote:I think I get it; I'm just not sure given the comments that pop up in the forum. Isn't one of the main reasons distinguishing between these two? void fun(ref const Foo); void fun(Foo); If they can't be distinguished, you don't get move semantics "for free". With the current rules: const Foo foo; fun(foo); // calls the first one, passes by ref fun(Foo()); // calls the second one, moves If rvalues can bind to const, then additional rules for picking one of the overloads have to be introduced. Even if that were done simply, I'm pretty sure a lot of people would believe they were moving when they weren't and vice-versa. There's a price to pay for the current rules: a possible loss of performance when passing large structs by value, since moving is more expensive than putting a pointer in a register (i.e. pass by ref). I believe this is why Manu wants rvalues to bind to const ref: to not pay that price.First, so that people get a nice prepared answer for why D is different. I can't confidently spell out why D doesn't allow passing an rvalues in a const ref parameter, and I suspect that only Andrei really can.He's explained it several times, but I confess that I've never really understood the reasoning. I know C++ well but not at the level of detail that seems to be required to understand what the exact problem is.Though as much as folks like passing rvalues to const ref in C++, isn't that generally considered to be bad practice now with C++11/14, because it doesn't play nicely with move constructors?Not really, no. There are cases where passing by value can generate faster code, but the guideline is still to pass by const T& as before when T is known. In generic code one should pass by T&& and std::forward everything. And, of course, if the performance difference really matters, measure const T& and by-value and go with whichever is fastest. But, by default, const T&. As mentioned above, moving is better than copying, but doing nothing at is usually better than moving. Or at least, there are many cases where you wouldhave used const ref previously that now you shouldn't, because it forces a copy for lvalues in some cases, whereas just passing by value would allow a move to be made?Sometimes even the move is elided, similarly to RVO and NRVO. Atila
Oct 18 2016
On 10/18/2016 04:15 PM, Atila Neves wrote:I think I get it; I'm just not sure given the comments that pop up in the forum. Isn't one of the main reasons distinguishing between these two? void fun(ref const Foo); void fun(Foo); If they can't be distinguished, you don't get move semantics "for free".That's right, thanks Atila. -- Andreu
Oct 18 2016
On Tuesday, 18 October 2016 at 20:22:58 UTC, Andrei Alexandrescu wrote:On 10/18/2016 04:15 PM, Atila Neves wrote:Is that really the only reason they aren't being allowed? Whenever I use const& in C++ I generally don't want to copy or move anything. How about adding a new qualifier? void func(ruleThemAll(Foo) foo); const Foo f; func(f); // ok func(Foo()); // ok // --- void func(ref ruleThemAll(Foo) foo); void func(ref const Foo); // error: ruleThemAll can have no overloads that match // function(Foo) or function(ref Foo)I think I get it; I'm just not sure given the comments that pop up in the forum. Isn't one of the main reasons distinguishing between these two? void fun(ref const Foo); void fun(Foo); If they can't be distinguished, you don't get move semantics "for free".That's right, thanks Atila. -- Andreu
Oct 18 2016
On Tuesday, 18 October 2016 at 20:22:58 UTC, Andrei Alexandrescu wrote:On 10/18/2016 04:15 PM, Atila Neves wrote:Actually thinking it over some more, you would be able to distinguish it. You would simply treat func(Foo) to be the equivalent of func(Foo&&) in C++. void func(ref const Foo); void func(Foo); enum ctfeFoo = Foo(); func(ctfeFoo); // calls func(ref const Foo); // zero reason to do a move as enum's can't house runtime values const Foo foo; func(foo); // calls func(ref const Foo); func(Foo()); // calls func(Foo) // no ambiguity, same reason there isn't one for C++'s && // Foo() is modifiable temporary import std.algorithms.mutation : move; Foo rfoo; func(move(rfoo)); // calls func(Foo) So now you would be able to define a single function to take both rvalues and lvalues.I think I get it; I'm just not sure given the comments that pop up in the forum. Isn't one of the main reasons distinguishing between these two? void fun(ref const Foo); void fun(Foo); If they can't be distinguished, you don't get move semantics "for free".That's right, thanks Atila. -- Andreu
Oct 18 2016
On 19 October 2016 at 06:22, Andrei Alexandrescu via Digitalmars-d < digitalmars-d puremagic.com> wrote:On 10/18/2016 04:15 PM, Atila Neves wrote:This is obvious though, lval calls the first, rval calls the second. Surely most programmers would intuitively expect that behaviour? Is there some issue there?I think I get it; I'm just not sure given the comments that pop up in the forum. Isn't one of the main reasons distinguishing between these two? void fun(ref const Foo); void fun(Foo); If they can't be distinguished, you don't get move semantics "for free".That's right, thanks Atila. -- Andreu
Oct 18 2016
On 10/19/16 1:47 AM, Manu via Digitalmars-d wrote:On 19 October 2016 at 06:22, Andrei Alexandrescu via Digitalmars-d <digitalmars-d puremagic.com <mailto:digitalmars-d puremagic.com>> wrote: On 10/18/2016 04:15 PM, Atila Neves wrote: I think I get it; I'm just not sure given the comments that pop up in the forum. Isn't one of the main reasons distinguishing between these two? void fun(ref const Foo); void fun(Foo); If they can't be distinguished, you don't get move semantics "for free". That's right, thanks Atila. -- Andreu This is obvious though, lval calls the first, rval calls the second. Surely most programmers would intuitively expect that behaviour? Is there some issue there?You're missing context. The conversation went like this: Jonathan: `Andrei said rvalue references were a mistake in C++' Andrei: `No, I said binding rvalues to const& was a mistake of C++, which subsequently led to the necessity of rvalue references.' Atila: `Indeed, if you cannot distinguish between void fun(ref const Foo) and void fun(Foo) then you're going to have a bad time.' (NOTA BENE: at this point it became unclear whether we discuss C++ or hypothetical D code. Atila used D syntax in a discussion about C++'s issue.) Me: `Affirmative.' You: `But wait, it's intuitive: lvalues bind to the first, rvalues bind to the last.' Well, I'd agree it's intuitive but C++ won't allow it. These overloads are ambiguous in C++ code: ============== struct S {}; void foo(S); void foo(const S&); // no error so far (which doesn't help either) int main() { S a; foo(a); // ERROR! Ambiguous call! const S b; foo(b); // ERROR! Ambiguous call! foo(S()); // ERROR! Ambiguous call! extern const S goo(); foo(goo()); // ERROR! Ambiguous call! } ============== This was C++'s big un' that led to many complications. If the overload weren't ambiguous, a large part of rvalue references would have been unneeded. (Universal references would still have been necessary for perfect forwarding, but that's not the bulk.) In order to avoid such issues, we steered clear off binding rvalues to ref parameters in the D language. As I mentioned to Ethan, I do agree a careful definition may be able to avoid the fallout that happened in C++. It would be a fair amount of work. Andrei
Oct 19 2016
On Wednesday, October 19, 2016 07:55:19 Andrei Alexandrescu via Digitalmars-d wrote:This was C++'s big un' that led to many complications. If the overload weren't ambiguous, a large part of rvalue references would have been unneeded. (Universal references would still have been necessary for perfect forwarding, but that's not the bulk.) In order to avoid such issues, we steered clear off binding rvalues to ref parameters in the D language. As I mentioned to Ethan, I do agree a careful definition may be able to avoid the fallout that happened in C++. It would be a fair amount of work.The other big problem is that D's const is so much more restrictive than C++'s that even if const ref accepted rvalues, a large portion of the time, it would be too restrictive to be useful. - Jonathan M Davis
Oct 19 2016
On 10/19/2016 11:38 AM, Jonathan M Davis via Digitalmars-d wrote:On Wednesday, October 19, 2016 07:55:19 Andrei Alexandrescu via Digitalmars-d wrote:That's why if we allow binding rvalues to references, we'd allow it regardless of const. -- AndreiThis was C++'s big un' that led to many complications. If the overload weren't ambiguous, a large part of rvalue references would have been unneeded. (Universal references would still have been necessary for perfect forwarding, but that's not the bulk.) In order to avoid such issues, we steered clear off binding rvalues to ref parameters in the D language. As I mentioned to Ethan, I do agree a careful definition may be able to avoid the fallout that happened in C++. It would be a fair amount of work.The other big problem is that D's const is so much more restrictive than C++'s that even if const ref accepted rvalues, a large portion of the time, it would be too restrictive to be useful.
Oct 19 2016
On Wednesday, October 19, 2016 12:48:54 Andrei Alexandrescu via Digitalmars-d wrote:On 10/19/2016 11:38 AM, Jonathan M Davis via Digitalmars-d wrote:Which then causes the problem that it becomes much less clear whether ref is supposed to be modifying its argument or is just trying to avoid copying it - though good documentation can mitigate that problem. - Jonathan M DavisOn Wednesday, October 19, 2016 07:55:19 Andrei Alexandrescu via Digitalmars-d> wrote:That's why if we allow binding rvalues to references, we'd allow it regardless of const. -- AndreiThis was C++'s big un' that led to many complications. If the overload weren't ambiguous, a large part of rvalue references would have been unneeded. (Universal references would still have been necessary for perfect forwarding, but that's not the bulk.) In order to avoid such issues, we steered clear off binding rvalues to ref parameters in the D language. As I mentioned to Ethan, I do agree a careful definition may be able to avoid the fallout that happened in C++. It would be a fair amount of work.The other big problem is that D's const is so much more restrictive than C++'s that even if const ref accepted rvalues, a large portion of the time, it would be too restrictive to be useful.
Oct 19 2016
On Wednesday, 19 October 2016 at 18:15:25 UTC, Jonathan M Davis wrote:Which then causes the problem that it becomes much less clear whether ref is supposed to be modifying its argument or is just trying to avoid copying it - though good documentation can mitigate that problem. - Jonathan M DavisAs long as it would be marked with scope (or some similar attribute) so that it cannot escape, it would be fine, wouldn't it?
Oct 19 2016
On Wednesday, October 19, 2016 18:18:43 Namespace via Digitalmars-d wrote:On Wednesday, 19 October 2016 at 18:15:25 UTC, Jonathan M Davis wrote:That's an orthogonal issue. My point is that normally, a parameter is a ref parameter, because the function is going to use that value and potentially mutate it in the process, and you want the original variable that was passed in to be mutated rather than for the function to be operating on a copy. However, once you can pass rvalues to ref parameters, there will likely be a sharp increase in the number of ref parameters whose entire purpose in being ref is to avoid a copy rather than because the original variable is supposed to be mutated. That increases the risk of accidentally mutating function arguments as well as making it far less obvious when a function is supposed to be mutating its argument. C++ solved that problem by making it so that only const ref parameters could take rvalues, whereas we would be totally open to it if non-const ref parameters accepted rvalues. Whether the argument escapes the function doesn't matter for any of that. There may be good reasons why you don't want it to, in which case, if scope is implemented to prevent ref parameters from escaping, scope will give you that. But just because you want to mutate the ref argument doesn't necessarily mean that you care about it escaping. You _do_ care if the purpose is simply to avoid a copy, because you don't want the rvalue to escape, since that would be an safety issue, and so it would make sense to require scope in that case, but at best, that means that the lack of scope indicates that the ref argument is supposed to be mutated as opposed to simply avoid a copy, whereas scope ref says nothing about whether the ref argument is supposed to be mutated or simply avoid a copy - just that whatever the argument is, it should no escape. So, arguably, it makes more sense to have a new attribute that makes it specifically so that a ref accepts rvalues (e.g. rvalue ref) rather than making ref in general accept rvalues (the new attribute could even imply scope, since it would be required), but that would mean adding yet another attribute, and we arguably have too many of those already. - Jonathan M DavisWhich then causes the problem that it becomes much less clear whether ref is supposed to be modifying its argument or is just trying to avoid copying it - though good documentation can mitigate that problem. - Jonathan M DavisAs long as it would be marked with scope (or some similar attribute) so that it cannot escape, it would be fine, wouldn't it?
Oct 19 2016
On Wednesday, 19 October 2016 at 19:19:35 UTC, Jonathan M Davis wrote:That's an orthogonal issue. My point is that normally, a parameter is a ref parameter, because the function is going to use that value and potentially mutate it in the process, and you want the original variable that was passed in to be mutated rather than for the function to be operating on a copy. However, once you can pass rvalues to ref parameters, there will likely be a sharp increase in the number of ref parameters whose entire purpose in being ref is to avoid a copy rather than because the original variable is supposed to be mutated. That increases the risk of accidentally mutating function arguments as well as making it far less obvious when a function is supposed to be mutating its argument. C++ solved that problem by making it so that only const ref parameters could take rvalues, whereas we would be totally open to it if non-const ref parameters accepted rvalues. Whether the argument escapes the function doesn't matter for any of that. There may be good reasons why you don't want it to, in which case, if scope is implemented to prevent ref parameters from escaping, scope will give you that. But just because you want to mutate the ref argument doesn't necessarily mean that you care about it escaping. You _do_ care if the purpose is simply to avoid a copy, because you don't want the rvalue to escape, since that would be an safety issue, and so it would make sense to require scope in that case, but at best, that means that the lack of scope indicates that the ref argument is supposed to be mutated as opposed to simply avoid a copy, whereas scope ref says nothing about whether the ref argument is supposed to be mutated or simply avoid a copy - just that whatever the argument is, it should no escape.Ok, I understand what you mean, but as long as the argument cannot escape I have a different opinion.So, arguably, it makes more sense to have a new attribute that makes it specifically so that a ref accepts rvalues (e.g. rvalue ref) rather than making ref in general accept rvalues (the new attribute could even imply scope, since it would be required), but that would mean adding yet another attribute, and we arguably have too many of those already. - Jonathan M DavisYes, we have way to many. So it would make more sense if we add helper/wrappers into phobos (at least for the time being) and refer to them. My byRef "hack" or even my last experiment below could lower the dissatisfaction. ---- struct Vector2f { float x, y; } void one(ref const Vector2f v) { writeln(v.x, '|', v.y); } void two(ref const Vector2f source, ref const Vector2f target) { writefln("From (%.2f|%.2f) to (%.2f|%.2f)", source.x, source.y, target.x, target.y); } void invoke(alias f, V...)(V vs) { f(vs); } void invoke(F, V...)(F f, V vs) { f(vs); } invoke!one(Vector2f(10, 20)); invoke!two(Vector2f(1, 2), Vector2f(3, 4)); invoke(&one, Vector2f(10, 20)); invoke(&two, Vector2f(1, 2), Vector2f(3, 4)); ----
Oct 19 2016
On 20 October 2016 at 04:18, Namespace via Digitalmars-d < digitalmars-d puremagic.com> wrote:On Wednesday, 19 October 2016 at 18:15:25 UTC, Jonathan M Davis wrote:Right, I was arguing this for years. Using 'scope' to make the concept safe. It seemed that it in the past the key reason for rejecting it was because it was unsafe to pass an rvalue-temp to a function where it's unknown if the function can cause it to outlive the function call... scope was the obvious resolution to that (along with a lot of other issues related to safety).Which then causes the problem that it becomes much less clear whether ref is supposed to be modifying its argument or is just trying to avoid copying it - though good documentation can mitigate that problem. - Jonathan M DavisAs long as it would be marked with scope (or some similar attribute) so that it cannot escape, it would be fine, wouldn't it?
Oct 19 2016
On 10/19/2016 5:26 PM, Manu via Digitalmars-d wrote:Right, I was arguing this for years. Using 'scope' to make the concept safe. It seemed that it in the past the key reason for rejecting it was because it was unsafe to pass an rvalue-temp to a function where it's unknown if the function can cause it to outlive the function call... scope was the obvious resolution to that (along with a lot of other issues related to safety).C++ has had two goes at rvalue references. Any serious proposal for that for D needs to include an analysis of what went right/wrong with the C++ one, and how the D one gets it right. The only way to move this forward is to write a DIP. Having the various bits of information spread out over various posts for months (years?) is never going to work.
Oct 19 2016
On 20 October 2016 at 11:04, Walter Bright via Digitalmars-d < digitalmars-d puremagic.com> wrote:On 10/19/2016 5:26 PM, Manu via Digitalmars-d wrote:We're not talking about rvalue references...? I'm not sure where this conversation got confused. The only way to move this forward is to write a DIP. Having the variousRight, I was arguing this for years. Using 'scope' to make the concept safe. It seemed that it in the past the key reason for rejecting it was because it was unsafe to pass an rvalue-temp to a function where it's unknown if the function can cause it to outlive the function call... scope was the obvious resolution to that (along with a lot of other issues related to safety).C++ has had two goes at rvalue references. Any serious proposal for that for D needs to include an analysis of what went right/wrong with the C++ one, and how the D one gets it right.bits of information spread out over various posts for months (years?) is never going to work.Like, 6 or 7 years ;) .. But I think we're talking about different things at this point.
Oct 19 2016
On 10/19/16 9:04 PM, Walter Bright wrote:The only way to move this forward is to write a DIP.I'd be willing to shepherd a DIP if a couple of people want to get serious about it. -- Andrei
Oct 19 2016
On 20 October 2016 at 01:38, Jonathan M Davis via Digitalmars-d < digitalmars-d puremagic.com> wrote:On Wednesday, October 19, 2016 07:55:19 Andrei Alexandrescu via Digitalmars-d wrote:I've never seen a piece of code in C++ that receives const& that isn't strictly read-only. I can't imagine from experience how D's const would change the usefulness of the pattern.This was C++'s big un' that led to many complications. If the overload weren't ambiguous, a large part of rvalue references would have been unneeded. (Universal references would still have been necessary for perfect forwarding, but that's not the bulk.) In order to avoid such issues, we steered clear off binding rvalues to ref parameters in the D language. As I mentioned to Ethan, I do agree a careful definition may be able to avoid the fallout that happened in C++. It would be a fair amount of work.The other big problem is that D's const is so much more restrictive than C++'s that even if const ref accepted rvalues, a large portion of the time, it would be too restrictive to be useful.
Oct 19 2016
On Tuesday, 18 October 2016 at 18:15:18 UTC, ag0aep6g wrote:It would be great if we had detailed rationale articles for these non-obvious decisions.We do, on the wiki: http://wiki.dlang.org/Language_design_discussions Feel free to add anything that you think would be of interest to others.
Oct 18 2016
On 10/18/2016 12:43 PM, bachmeier wrote:On Tuesday, 18 October 2016 at 18:15:18 UTC, ag0aep6g wrote:http://wiki.dlang.org/Language_design_discussions#rvalue_referencesIt would be great if we had detailed rationale articles for these non-obvious decisions.We do, on the wiki: http://wiki.dlang.org/Language_design_discussions Feel free to add anything that you think would be of interest to others.
Oct 18 2016
On 18.10.2016 20:15, ag0aep6g wrote:On 10/18/2016 07:51 PM, Jonathan M Davis via Digitalmars-d wrote:It wouldn't even be the same thing if it was allowed. D const is not C++ const. Enforcing transitive read-only on rvalue references does not make that much sense. If rvalues shouldn't be allowed to bind to ref alone, there should just be some additional annotation that allows rvalues to bind to ref, but that additional annotation shouldn't do anything more.Andrei decided ages ago that he didn't think that having const ref take rvalues was a good idea and that he doesn't think that it's a big deal. I don't recall whether Walter has said much on the issue, but AFAIK, he hasn't said anything to contradict that, and Andrei has been very vocal about how rvalue references were a horrible mistake in C++ and that he doesn't want to see anything of the sort in D.It would be great if we had detailed rationale articles for these non-obvious decisions. First, so that people get a nice prepared answer for why D is different.
Oct 18 2016
Am Tue, 18 Oct 2016 22:43:01 +0200 schrieb Timon Gehr <timon.gehr gmx.ch>:It wouldn't even be the same thing if it was allowed. D const is not C++ const. Enforcing transitive read-only on rvalue references does not make that much sense.For me using const ref vs. const is typically entirely a matter of avoiding a costly copy. The function body shouldn't care whether the data came from an rvalue or lvalue. It is exemplified in the following lines where doSomething takes a const ref and worldTransform returns by value: const worldTransform = someObj.worldTransform(); otherObj.doSomething(arg1, arg2, worldTransform); I'd prefer to write: otherObj.doSomething(arg1, arg2, someObj.worldTransform()); as the temporaries add significant noise in some functions and make the equivalent C++ code look cleaner. It may be noteworthy that the lack of rvalue references only really got annoying for me with matrix calculations, because there are so many medium sized temporaries. Some of them come directly from binary operators. Functions often need to perform a set of computations that bare a lot of similarity, where visual cues help the understanding. In a reduced form: calculate( matrix); // works calculate(2*matrix); // doesn't work, requires temporary calculate(3*matrix); // " Introducing temporaries makes the similarity of the calculation less evident. Making calculate take auto-ref would result in duplicate code and thrash the instruction cache (especially with 2 or 3 arguments). Dropping "ref" results in unnecessary matrix copies at this and other call sites. -- Marco
Oct 18 2016
On 19.10.2016 04:58, Marco Leise wrote:Am Tue, 18 Oct 2016 22:43:01 +0200 schrieb Timon Gehr <timon.gehr gmx.ch>:Yes, the lack of rvalue references can be annoying but 'const' should be orthogonal to any implemented solution. There should be a way to pass rvalues by reference that are not prevented from being mutated, and it should be the same way as for const references. (For example, one possible approach is to just allow rvalues to bind to all 'ref' parameters (as is done for the implicit 'this' reference), alternatively there could be some additional "allow rvalues here" annotation that does not influence mutability.)It wouldn't even be the same thing if it was allowed. D const is not C++ const. Enforcing transitive read-only on rvalue references does not make that much sense.For me using const ref vs. const is typically entirely a matter of avoiding a costly copy. The function body shouldn't care whether the data came from an rvalue or lvalue. It is exemplified in the following lines where doSomething takes a const ref and worldTransform returns by value: const worldTransform = someObj.worldTransform(); otherObj.doSomething(arg1, arg2, worldTransform); I'd prefer to write: otherObj.doSomething(arg1, arg2, someObj.worldTransform()); as the temporaries add significant noise in some functions and make the equivalent C++ code look cleaner. It may be noteworthy that the lack of rvalue references only really got annoying for me with matrix calculations, because there are so many medium sized temporaries. Some of them come directly from binary operators. Functions often need to perform a set of computations that bare a lot of similarity, where visual cues help the understanding. In a reduced form: calculate( matrix); // works calculate(2*matrix); // doesn't work, requires temporary calculate(3*matrix); // " Introducing temporaries makes the similarity of the calculation less evident. Making calculate take auto-ref would result in duplicate code and thrash the instruction cache (especially with 2 or 3 arguments). Dropping "ref" results in unnecessary matrix copies at this and other call sites.
Oct 19 2016
Am Wed, 19 Oct 2016 11:29:50 +0200 schrieb Timon Gehr <timon.gehr gmx.ch>:Yes, the lack of rvalue references can be annoying but 'const' should be orthogonal to any implemented solution. There should be a way to pass rvalues by reference that are not prevented from being mutated, and it should be the same way as for const references. (For example, one possible approach is to just allow rvalues to bind to all 'ref' parameters (as is done for the implicit 'this' reference), alternatively there could be some additional "allow rvalues here" annotation that does not influence mutability.)Ok, got ya now! -- Marco
Oct 19 2016
On 10/18/2016 11:15 AM, ag0aep6g wrote:It would be great if we had detailed rationale articles for these non-obvious decisions.That's what FAQs are for, and if someone wants to collect Andrei's posts on the matter and distill them into a FAQ: Why doesn't D do rvalue references? that would be most helpful. Even if the FAQ entry is not perfect, it will serve as a place to provide clarification, rather than random n.g. bits. http://dlang.org/faq.html http://www.prowiki.org/wiki4d/wiki.cgi?FaqRoadmap
Oct 18 2016
On Tuesday, 18 October 2016 at 17:51:19 UTC, Jonathan M Davis wrote:On Tuesday, October 18, 2016 13:36:42 Namespace via Digitalmars-d wrote:Yep. Therefore my little hack. It works and it isn't such a big inconvenience.On Tuesday, 18 October 2016 at 09:50:35 UTC, ketmar wrote:Andrei decided ages ago that he didn't think that having const ref take rvalues was a good idea and that he doesn't think that it's a big deal. I don't recall whether Walter has said much on the issue, but AFAIK, he hasn't said anything to contradict that, and Andrei has been very vocal about how rvalue references were a horrible mistake in C++ and that he doesn't want to see anything of the sort in D. auto ref parameters solve the problem on some level, and it seems that that's the closest you're going to get to getting rvalue references in the language. I think that it's pretty clear at this point that it's not very likely that anyone is going to change Andrei's mind on this one. - Jonathan M DavisOn Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:True. ;) It's like the static-array-without-length-and-gc hack. You can do it with language constructs but it's inconvenient. So it's up to Walter and Andrei to decide if this inconvenience is bearable or not.On Tuesday, 18 October 2016 at 02:54:08 UTC, Manu wrote:there is a huge difference between "i can hack around it" and "i can do it".I just want to be able to pass an rvalue to a function that receives a const ref... that's why I came to this forum in the first place like, 7 years ago. 7 years later... still can't.I recently wrote a PR for p0nce D idioms, which shows how you can do that https://github.com/p0nce/d-idioms/pull/119
Oct 18 2016
On 19 October 2016 at 03:51, Jonathan M Davis via Digitalmars-d < digitalmars-d puremagic.com> wrote:On Tuesday, October 18, 2016 13:36:42 Namespace via Digitalmars-d wrote:Don't misunderstand, at no point I'm aware has anyone ever talked about rval references. This is all about passing rvalues as normal references. People just want to be able to do this: void f(ref const(Vector) v); f(v1 + v2); or: f(Vector(10,20,30)); That is all. The rval produces a temporary, and the temporary is passed to the function.On Tuesday, 18 October 2016 at 09:50:35 UTC, ketmar wrote:Andrei decided ages ago that he didn't think that having const ref take rvalues was a good idea and that he doesn't think that it's a big deal. I don't recall whether Walter has said much on the issue, but AFAIK, he hasn't said anything to contradict that, and Andrei has been very vocal about how rvalue references were a horrible mistake in C++ and that he doesn't want to see anything of the sort in D.On Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:True. ;) It's like the static-array-without-length-and-gc hack. You can do it with language constructs but it's inconvenient. So it's up to Walter and Andrei to decide if this inconvenience is bearable or not.On Tuesday, 18 October 2016 at 02:54:08 UTC, Manu wrote:there is a huge difference between "i can hack around it" and "i can do it".I just want to be able to pass an rvalue to a function that receives a const ref... that's why I came to this forum in the first place like, 7 years ago. 7 years later... still can't.I recently wrote a PR for p0nce D idioms, which shows how you can do that https://github.com/p0nce/d-idioms/pull/119
Oct 18 2016
On Wednesday, 19 October 2016 at 05:41:17 UTC, Manu wrote:People just want to be able to do this: void f(ref const(Vector) v); f(v1 + v2); or: f(Vector(10,20,30)); That is all. The rval produces a temporary, and the temporary is passed to the function.Probably worth pointing out that we laid it out exactly like this to Walter and Andrei at DConf, and how not having it made the Quantum Break animation code (all of which is 3D math) a pain to write thanks to having to define the temporary variables yourself. Especially when you're calling bound C++ functions and the programmers involved could compare it to C++ directly saying "Why can't we do this?" This was actually a use case that had not been considered before, as it turns out.
Oct 19 2016
On 19 October 2016 at 19:11, Ethan Watson via Digitalmars-d < digitalmars-d puremagic.com> wrote:On Wednesday, 19 October 2016 at 05:41:17 UTC, Manu wrote:Huh? Not even. I dunno how it could have not been considered, since it was the exact example I've given every time, and the exact case that motivated my first (and many subsequent) posts on this forum back when we still worked at Krome.. all this time later I *still* just wanna call functions in games engines that receive a vector or matrix ;)People just want to be able to do this: void f(ref const(Vector) v); f(v1 + v2); or: f(Vector(10,20,30)); That is all. The rval produces a temporary, and the temporary is passed to the function.Probably worth pointing out that we laid it out exactly like this to Walter and Andrei at DConf, and how not having it made the Quantum Break animation code (all of which is 3D math) a pain to write thanks to having to define the temporary variables yourself. Especially when you're calling bound C++ functions and the programmers involved could compare it to C++ directly saying "Why can't we do this?" This was actually a use case that had not been considered before, as it turns out.
Oct 19 2016
On Wednesday, 19 October 2016 at 09:34:39 UTC, Manu wrote:I dunno how it could have not been considered, since it was the exact example I've given every time, and the exact case that motivated my first (and many subsequent) posts on this forum back when we still worked at Krome.. all this time later I *still* just wanna call functions in games engines that receive a vector or matrix ;)Well, it could very well have been the specifics as we laid it out that weren't considered, ie avoiding temporary variables that we never use again; and taking by const reference to avoid copying the struct to the stack (whether just created or already previously stored on the stack etc). Win64 also has the __vectorcall calling convention, but that doesn't help in cases where you pass in several matrices as inputs for example. And it's not portable to other viable gaming platforms. https://msdn.microsoft.com/en-us/library/dn375768.aspx
Oct 19 2016
On 10/19/2016 2:11 AM, Ethan Watson wrote:On Wednesday, 19 October 2016 at 05:41:17 UTC, Manu wrote:void f(ref Vector v); void fv(Vector v) { f(v); } fv(Vector(10,20,30)); fv gets inlined, so no overhead.People just want to be able to do this: void f(ref const(Vector) v); f(v1 + v2); or: f(Vector(10,20,30)); That is all. The rval produces a temporary, and the temporary is passed to the function.Probably worth pointing out that we laid it out exactly like this to Walter and Andrei at DConf, and how not having it made the Quantum Break animation code (all of which is 3D math) a pain to write thanks to having to define the temporary variables yourself. Especially when you're calling bound C++ functions and the programmers involved could compare it to C++ directly saying "Why can't we do this?"
Oct 19 2016
Better: void f(ref Vector v); void f(Vector v) { f(v); } f(Vector(10,20,30));
Oct 19 2016
On Wednesday, 19 October 2016 at 10:32:56 UTC, Walter Bright wrote:Better: void f(ref Vector v); void f(Vector v) { f(v); } f(Vector(10,20,30));Suitable enough for simple functions. But beyond that becomes maintenance hell. For example: void func2( ref const( Vector ) v1, ref const( Vector ) v2 ); Requires the following permutations: void func2( const( Vector ) v1, ref const( Vector ) v2 ) { func2( v1, v2 ); } void func2( ref const( Vector ) v1, const( Vector ) v2 ) { func2( v1, v2 ); } void func2( const( Vector ) v1, const( Vector ) v2 ) { func2( v1, v2 ); } For example: void func3( ref const( Vector ) v1, ref const( Vector ) v2, ref const( Vector ) v3 ); Requires the following permutations: void func3( const( Vector ) v1, const( Vector ) v2, const( Vector ) v3 ) { func3( v1, v2, v3 ); } void func3( ref const( Vector ) v1, const( Vector ) v2, const( Vector ) v3 ) { func3( v1, v2, v3 ); } void func3( ref const( Vector ) v1, ref const( Vector ) v2, const( Vector ) v3 ) { func3( v1, v2, v3 ); } void func3( ref const( Vector ) v1, const( Vector ) v2, ref const( Vector ) v3 ) { func3( v1, v2, v3 ); } void func3( const( Vector ) v1, ref const( Vector ) v2, ref const( Vector ) v3 ) { func3( v1, v2, v3 ); } void func3( const( Vector ) v1, const( Vector ) v2, ref const( Vector ) v3 ) { func3( v1, v2, v3 ); } void func3( const( Vector ) v1, ref const( Vector ) v2, const( Vector ) v3 ) { func3( v1, v2, v3 ); } Did I miss one in that block? I think I missed one. Thus my point. If you were to provide something that Just Works(TM) out of the box for all possible creation states of your ref variables, you need to permute on all the ref parameters in your function. Which is either a process prone to human error; or in automated binding code, more things to parse at compile time resulting in slower compile times.
Oct 20 2016
On Thursday, 20 October 2016 at 10:23:40 UTC, Ethan Watson wrote:On Wednesday, 19 October 2016 at 10:32:56 UTC, Walter Bright wrote:---- auto invoke(F, V...)(F f, V vs) { return f(vs); } invoke(&func2, Vector(1, 2, 3), Vector(4, 5, 6)); ---- One function to rule them all. :oBetter: void f(ref Vector v); void f(Vector v) { f(v); } f(Vector(10,20,30));Suitable enough for simple functions. But beyond that becomes maintenance hell. For example: void func2( ref const( Vector ) v1, ref const( Vector ) v2 );
Oct 20 2016
On 10/20/2016 06:23 AM, Ethan Watson wrote:On Wednesday, 19 October 2016 at 10:32:56 UTC, Walter Bright wrote:I agree this workaround has a combinatorial problem. Again, lest this got lost: I think a solid DIP addressing the problem would have a good chance to get traction. We are in a better place than we used to with handling ref, and also with the general understanding of the general matter and how it was problematic for C++. I'm thinking a DIP would work well around the following lines: * Explain the problem with well-motivated examples. * Related work and workarounds, most notably "auto ref" in templates. Explain how "auto ref" is insufficient. Explain how workarounds are insufficient. * Propose a semantics that would address the problem. By far the preferred way is by means of a lowering to existing language. The obvious lowering is to have the compiler introduce "auto" variables prior to the call, as follows: In the call fun(e1, e2), if e1 and e2 are rvalues and fun specifies it accepts an rvalue by reference for both parameters, the lowering is: fun(e1, e2) => { auto __1 = e1, __2 = e2; return fun(__1, __2); }() There are potential issues with fun returning ref, which the DIP should address. * Propose an annotation to indicate the function allows rvalues. What comes to mind: (a) Expand the use of "auto ref" to nontemplates. The common objection to this is we'd have the same syntax express subtly different semantics (for templates there are two distinct functions generated, and inside the template it is possible to distinguish between the two). The DIP should address this objection. (b) Use an attribute, e.g. void fun( rvalue ref Vector); * Discuss how the annotation affects function signature and mangling (not sure but probably there should be no effect). * Sketch the changes to the language definitions. Thanks, AndreiBetter: void f(ref Vector v); void f(Vector v) { f(v); } f(Vector(10,20,30));Suitable enough for simple functions. But beyond that becomes maintenance hell.
Oct 20 2016
On 10/20/2016 12:49 PM, Andrei Alexandrescu wrote:On 10/20/2016 06:23 AM, Ethan Watson wrote:Yes, Ethan made a good point I hadn't thought of. And any DIP on the matter should cover this point (else it will come up again). These sorts of things are why a DIP should be done - to collect all these points in one place.Suitable enough for simple functions. But beyond that becomes maintenance hell.I agree this workaround has a combinatorial problem.
Oct 20 2016
On 10/20/2016 04:57 PM, Walter Bright wrote:On 10/20/2016 12:49 PM, Andrei Alexandrescu wrote:The combinatorial explosion was one core motivation for C++ rvalue references. I think the authors of the would-be DIP would do good to be conversant with that proposal. -- AndreiOn 10/20/2016 06:23 AM, Ethan Watson wrote:Yes, Ethan made a good point I hadn't thought of. And any DIP on the matter should cover this point (else it will come up again). These sorts of things are why a DIP should be done - to collect all these points in one place.Suitable enough for simple functions. But beyond that becomes maintenance hell.I agree this workaround has a combinatorial problem.
Oct 20 2016
On 10/20/2016 2:53 PM, Andrei Alexandrescu wrote:The combinatorial explosion was one core motivation for C++ rvalue references. I think the authors of the would-be DIP would do good to be conversant with that proposal. -- Andrei"However, as the number of free parameters grows (as in bind and function), this solution quickly grows impractical. The number of overloads required increases exponentially with the number of parameters (2N where N is the number of parameters)." Proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html Spec changes: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html
Oct 20 2016
On 21 October 2016 at 06:57, Walter Bright via Digitalmars-d < digitalmars-d puremagic.com> wrote:On 10/20/2016 12:49 PM, Andrei Alexandrescu wrote:Shoot me! ;)On 10/20/2016 06:23 AM, Ethan Watson wrote:Yes, Ethan made a good point I hadn't thought of.Suitable enough for simple functions. But beyond that becomes maintenance hell.I agree this workaround has a combinatorial problem.
Oct 20 2016
On Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote:I think a solid DIP addressing the problem would have a good chance to get traction.I think all the information in this thread and the "Binding rvalues to const ref in D" thread that Atilla started is enough for me to write up a solid DIP. I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly.
Oct 21 2016
On 10/21/2016 12:56 AM, Ethan Watson wrote:I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly.Great!
Oct 21 2016
On 10/21/2016 04:47 AM, Walter Bright wrote:On 10/21/2016 12:56 AM, Ethan Watson wrote:I, too, will look forward to that. If we get it right, we'll have a prototype of a good DIP to serve as an example for future submissions. By the way, the deadline for looking at https://github.com/dlang/DIPs/blob/master/DIPs/DIP1001.md and https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md is October 30, please make sure it is as good as it can be before that. Thanks, AndreiI'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly.Great!
Oct 21 2016
On 21.10.2016 09:56, Ethan Watson wrote:On Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote:Nice! Make sure it is orthogonal to const. :)I think a solid DIP addressing the problem would have a good chance to get traction.I think all the information in this thread and the "Binding rvalues to const ref in D" thread that Atilla started is enough for me to write up a solid DIP. I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly.
Oct 21 2016
On 10/21/16 5:39 PM, Timon Gehr wrote:On 21.10.2016 09:56, Ethan Watson wrote:It would be great if you participated. Such a DIP needs you. -- AndreiOn Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote:Nice! Make sure it is orthogonal to const. :)I think a solid DIP addressing the problem would have a good chance to get traction.I think all the information in this thread and the "Binding rvalues to const ref in D" thread that Atilla started is enough for me to write up a solid DIP. I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly.
Oct 21 2016
On 22.10.2016 03:10, Andrei Alexandrescu wrote:On 10/21/16 5:39 PM, Timon Gehr wrote:I'm ready to participate (but I can't invest too much time at the moment). Are we going with rvalue ref?On 21.10.2016 09:56, Ethan Watson wrote:It would be great if you participated. Such a DIP needs you. -- AndreiOn Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote:Nice! Make sure it is orthogonal to const. :)I think a solid DIP addressing the problem would have a good chance to get traction.I think all the information in this thread and the "Binding rvalues to const ref in D" thread that Atilla started is enough for me to write up a solid DIP. I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly.
Oct 22 2016
On Saturday, October 22, 2016 23:13:28 Timon Gehr via Digitalmars-d wrote:I'm ready to participate (but I can't invest too much time at the moment). Are we going with rvalue ref?That would certainly be my preference - at least out of what's been discussed thus far. - Jonathan M Davis
Oct 22 2016
On Saturday, 22 October 2016 at 22:05:54 UTC, Jonathan M Davis wrote:On Saturday, October 22, 2016 23:13:28 Timon Gehr via Digitalmars-d wrote:With move semantics in mind, I'm wondering if there may be a better word. Currently in D, IIRC, explicit moving can be done through by-value arguments. If you want to move explicitly from an lvalue, you can use D's std.move(lvalue). The downside is an extra blit/init into the rvalue that's returned by std.move. Then, the function that takes the rvalue may blit again in order to store the contents that are being moved in. As an alternative, non-const ' rvalue ref param' could be used...but would it be clear enough to people(seeing non-const rvalue) that the contents of the argument could potentially be consumed/moved-from?I'm ready to participate (but I can't invest too much time at the moment). Are we going with rvalue ref?That would certainly be my preference - at least out of what's been discussed thus far. - Jonathan M Davis
Oct 22 2016
On Friday, 21 October 2016 at 07:56:40 UTC, Ethan Watson wrote:On Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote:Any news on this?I think a solid DIP addressing the problem would have a good chance to get traction.I think all the information in this thread and the "Binding rvalues to const ref in D" thread that Atilla started is enough for me to write up a solid DIP. I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly.
Oct 28 2016
On Friday, 28 October 2016 at 21:05:33 UTC, bitwise wrote:On Friday, 21 October 2016 at 07:56:40 UTC, Ethan Watson wrote:Hmm. Why did I expect this? -_-On Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote:Any news on this?I think a solid DIP addressing the problem would have a good chance to get traction.I think all the information in this thread and the "Binding rvalues to const ref in D" thread that Atilla started is enough for me to write up a solid DIP. I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly.
Oct 29 2016
On 10/19/16 5:11 AM, Ethan Watson wrote:On Wednesday, 19 October 2016 at 05:41:17 UTC, Manu wrote:"Because you're trying to write C++ in D." :o) I'm just kidding. I agree it's occasionally unpleasant to have the calling convention impose l/rvalueness depending on by ref/by value signature. With the recent tightening of ref semantics, and if we carefully navigate around C++'s mistake, we may be able to define a way to meaningfully bind rvalues to ref. It's a fair amount of work, worth a thorough DIP. Implementation is the easy part (for the most part lifting restrictions). AndreiPeople just want to be able to do this: void f(ref const(Vector) v); f(v1 + v2); or: f(Vector(10,20,30)); That is all. The rval produces a temporary, and the temporary is passed to the function.Probably worth pointing out that we laid it out exactly like this to Walter and Andrei at DConf, and how not having it made the Quantum Break animation code (all of which is 3D math) a pain to write thanks to having to define the temporary variables yourself. Especially when you're calling bound C++ functions and the programmers involved could compare it to C++ directly saying "Why can't we do this?"
Oct 19 2016
On Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:On Tuesday, 18 October 2016 at 02:54:08 UTC, Manu wrote:Just wanted to add that I still don't know (I'm lazy) what "auto ref" parameters, "auto ref" return, and friends do in D. ref is somewhat easy to explain in C++ but complicated in D.I just want to be able to pass an rvalue to a function that receives a const ref... that's why I came to this forum in the first place like, 7 years ago. 7 years later... still can't.I recently wrote a PR for p0nce D idioms, which shows how you can do that https://github.com/p0nce/d-idioms/pull/119
Oct 19 2016
On Wednesday, 19 October 2016 at 17:42:39 UTC, Guillaume Piolat wrote:On Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:For each auto ref argument the compiler will lazily generate 2^N functions (therefore "template bloat" if you overdo it). Example: ---- struct A { int id; } void test(T)(auto ref T a) { } A a = A(42); test(a); ---- will generate one function, which takes the argument by ref: ---- void test(ref A a) { } ---- Another call ---- test(A(42)); ---- will generate another function, which takes the argument by value: ---- void test(A a) { } ---- That's more ore less the magic behind auto ref.On Tuesday, 18 October 2016 at 02:54:08 UTC, Manu wrote:Just wanted to add that I still don't know (I'm lazy) what "auto ref" parameters, "auto ref" return, and friends do in D. ref is somewhat easy to explain in C++ but complicated in D.I just want to be able to pass an rvalue to a function that receives a const ref... that's why I came to this forum in the first place like, 7 years ago. 7 years later... still can't.I recently wrote a PR for p0nce D idioms, which shows how you can do that https://github.com/p0nce/d-idioms/pull/119
Oct 19 2016
On Wednesday, 19 October 2016 at 17:54:15 UTC, Namespace wrote:That's more ore less the magic behind auto ref.Thanks. Failed to find the related bit in the spec.
Oct 19 2016
On Sunday, 16 October 2016 at 22:17:15 UTC, deadalnix wrote:[...]FWIW ;) https://www.youtube.com/watch?v=_wzc7a3McOs&feature=youtu.be?list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH&t=3757
Oct 17 2016
On Thursday, October 20, 2016 10:23:35 Manu via Digitalmars-d wrote:On 20 October 2016 at 01:38, Jonathan M Davis via Digitalmars-d < digitalmars-d puremagic.com> wrote:The transitivity of const shoot stuff in the foot pretty thoroughly in a number of cases. A prime example would be ranges, because they have to be mutated to be iterated over. If the function actually took a range directly, you wouldn't bother with const ref, but it could be an object that contains a range, and because you can't normally get a tail-const range from a const range (aside from dynamic arrays), it can become quite difficult to actually iterate over the range. e.g. auto foo(ref const(Bar) bar) { auto range = bar.getSomeRange(); ... } Because getSomeRange would have to be const (or inout) in order to be called, the return type is going to have be const if there are any indirections in it. And if it's const, and it's a range, it's useless. If this were C++, const wouldn't be transitive, so it would be trivial to get an iterator or range which wasn't const and did not violate const or attempt to work around it in any way and thus could be iterated. But in D, const is far too restrictive for that to work. This is the kind of problem that quickly makes you start wondering whether it's even worth trying to use const in D at all. - Jonathan M DavisOn Wednesday, October 19, 2016 07:55:19 Andrei Alexandrescu via Digitalmars-d wrote:I've never seen a piece of code in C++ that receives const& that isn't strictly read-only. I can't imagine from experience how D's const would change the usefulness of the pattern.This was C++'s big un' that led to many complications. If the overload weren't ambiguous, a large part of rvalue references would have been unneeded. (Universal references would still have been necessary for perfect forwarding, but that's not the bulk.) In order to avoid such issues, we steered clear off binding rvalues to ref parameters in the D language. As I mentioned to Ethan, I do agree a careful definition may be able to avoid the fallout that happened in C++. It would be a fair amount of work.The other big problem is that D's const is so much more restrictive than C++'s that even if const ref accepted rvalues, a large portion of the time, it would be too restrictive to be useful.
Oct 19 2016
On Thursday, 20 October 2016 at 01:04:35 UTC, Jonathan M Davis wrote:The transitivity of const shoot stuff in the foot pretty thoroughly in a number of cases. A prime example would be ranges, because they have to be mutated to be iterated over. If the function actually took a range directly, you wouldn't bother with const ref, but it could be an object that contains a range, and because you can't normally get a tail-const range from a const range (aside from dynamic arrays), it can become quite difficult to actually iterate over the range. e.g. auto foo(ref const(Bar) bar) { auto range = bar.getSomeRange(); ... }Is it legal to `.save` a const range, and then use it (provided it does not mutate any object reachable from bar)?Because getSomeRange would have to be const (or inout) in order to be called, the return type is going to have be const if there are any indirections in it. And if it's const, and it's a range, it's useless. If this were C++, const wouldn't be transitive, so it would be trivial to get an iterator or range which wasn't const and did not violate const or attempt to work around it in any way and thus could be iterated. But in D, const is far too restrictive for that to work. This is the kind of problem that quickly makes you start wondering whether it's even worth trying to use const in D at all. - Jonathan M Davis
Oct 20 2016
On 10/21/2016 01:18 AM, Nicholas Wilson wrote:Is it legal to `.save` a const range, and then use it (provided it does not mutate any object reachable from bar)?Sure, if it doesn't involve a cast, i.e. if save is const.
Oct 20 2016
On Thursday, October 20, 2016 23:18:14 Nicholas Wilson via Digitalmars-d wrote:On Thursday, 20 October 2016 at 01:04:35 UTC, Jonathan M Davis wrote:Not really. isForwardRange requires that save return _exactly_ the same type as the range. So, it really can't work as a const function (and const(MyRangeType) will never pass isInputRange or isFowardRange, because popFront won't compile). You _can_ declare an overload of save that's const and returns something different, but then it's not actually part of the range API, and you can't rely on it working. At that point, you might as well make up your own function, since what you're doing is non-standand anyway. Regardless of all that though, it's not always even possible for a range to have a function that returns a tail-const version of the range because of how the internals of the range work. So, even if we had a standard way to deal with that, it couldn't work in all cases, and really, it would have to be dealt with separately from traits like isForwardRange. Arguably, to match arrays, we should be defining an opSlice for ranges which returns a tail-const version of the range (and then we could have a trait like hasTailConstSlicing), but that's not currently part of the range API, and it's actually pretty hard to define even for simple ranges (e.g. you have to use static if carefully to avoid recursive template instantiations). So, the best way to handle this is very much an open question. For now, the reality of the matter is that there is no standard way for const ranges to work. - Jonathan M DavisThe transitivity of const shoot stuff in the foot pretty thoroughly in a number of cases. A prime example would be ranges, because they have to be mutated to be iterated over. If the function actually took a range directly, you wouldn't bother with const ref, but it could be an object that contains a range, and because you can't normally get a tail-const range from a const range (aside from dynamic arrays), it can become quite difficult to actually iterate over the range. e.g. auto foo(ref const(Bar) bar) { auto range = bar.getSomeRange(); ... }Is it legal to `.save` a const range, and then use it (provided it does not mutate any object reachable from bar)?
Oct 21 2016