www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - I close BIP27. I won't be pursuing BIPs anymore

reply deadalnix <deadalnix gmail.com> writes:
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
next sibling parent Nick Sabalausky <a a.a> writes:
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
prev sibling next sibling parent reply Dicebot <public dicebot.lv> writes:
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
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
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
parent Dicebot <public dicebot.lv> writes:
 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:

 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.


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--
Oct 20 2016
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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 intended


Well, 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
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/17/2016 02:39 AM, Jacob Carlborg wrote:

 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 intended


 Well, the designed of the DIP process if flawed.


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.


 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
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
prev sibling parent reply David Soria Parra <dsp experimentalworks.net> writes:
On Monday, 17 October 2016 at 06:58:59 UTC, Andrei Alexandrescu 
wrote:

 On 10/17/2016 02:39 AM, Jacob Carlborg wrote:

 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 
 intended


 Well, the designed of the DIP process if flawed.


 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.


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.
Oct 17 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
parent reply David Soria Parra <dsp experimentalworks.net> writes:
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
parent Dicebot <public dicebot.lv> writes:
 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=


t

 is 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=


d

 contributors 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
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.md



 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.


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
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/17/2016 01:02 AM, Walter Bright wrote:

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

Andrei
Oct 16 2016
parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 17 October 2016 at 06:43:21 UTC, Andrei Alexandrescu 
wrote:

 On 10/17/2016 01:02 AM, Walter Bright wrote:

 [...]


 I understand your frustration and please bear with us while 
 we're arranging the DIP process to guarantee timely response.

 [...]


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.
Oct 17 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 17 October 2016 at 08:29:27 UTC, Walter Bright wrote:

 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.


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.
Oct 17 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/17/16 4:57 AM, Joakim wrote:

 On Monday, 17 October 2016 at 08:29:27 UTC, Walter Bright wrote:

 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.


 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.


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.

-Steve
Oct 17 2016
parent Joakim <dlang joakim.fea.st> writes:
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
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, October 17, 2016 01:29:27 Walter Bright via Digitalmars-d wrote:

 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.


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 Davis
Oct 17 2016
prev sibling next sibling parent reply ZombineDev <petar.p.kirov gmail.com> writes:
On Monday, 17 October 2016 at 05:02:52 UTC, Walter Bright wrote:

 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.


https://github.com/dlang/DIPs/pull/16
Oct 17 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/17/2016 12:45 AM, ZombineDev wrote:

 https://github.com/dlang/DIPs/pull/16


Thanks. I hadn't seen it earlier because I had neglected to look in the closed
list.
Oct 17 2016
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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:

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



 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.



 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.


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.
Oct 17 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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:


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


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.


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



prev sibling  parent  Shachar Shemesh <shachar weka.io>  writes:


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



prev sibling  parent reply Namespace <rswhite4 gmail.com>  writes:


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



 next sibling parent reply ketmar <ketmar ketmar.no-ip.org>  writes:


On Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:

 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


there is a huge difference between "i can hack around it" and "i 
can do it".



 Oct 18 2016



  parent reply Namespace <rswhite4 gmail.com>  writes:


On Tuesday, 18 October 2016 at 09:50:35 UTC, ketmar wrote:

 On Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:

 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


 there is a huge difference between "i can hack around it" and 
 "i can do it".


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.



 Oct 18 2016



 next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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:

 On Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:

 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


 there is a huge difference between "i can hack around it" and
 "i can do it".


 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.


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 Davis



 Oct 18 2016



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 next sibling parent  Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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:

 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


LOL. Sorry, I got the basic idea right but not the specifics. Thanks for the
clarification.

- Jonathan M Davis



 Oct 18 2016



prev sibling  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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:


 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


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?



 Oct 18 2016



prev sibling next sibling parent reply ag0aep6g <anonymous example.com>  writes:


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



 next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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



  parent reply Atila Neves <atila.neves gmail.com>  writes:


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:

 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.


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.


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


Sometimes even the move is elided, similarly to RVO and NRVO.

Atila



 Oct 18 2016



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 next sibling parent  Jacob <noreply noreply.com>  writes:


On Tuesday, 18 October 2016 at 20:22:58 UTC, Andrei Alexandrescu 
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


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)



 Oct 18 2016



prev sibling next sibling parent  Jacob <noreply noreply.com>  writes:


On Tuesday, 18 October 2016 at 20:22:58 UTC, Andrei Alexandrescu 
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


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.



 Oct 18 2016



prev sibling  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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:


 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?



 Oct 18 2016



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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:

 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.


That's why if we allow binding rvalues to references, we'd allow it 
regardless of const. -- Andrei



 Oct 19 2016



  parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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:

 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.


 That's why if we allow binding rvalues to references, we'd allow it
 regardless of const. -- Andrei


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 Davis



 Oct 19 2016



  parent reply Namespace <rswhite4 gmail.com>  writes:


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 Davis


As 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



 next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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:

 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 Davis


 As long as it would be marked with scope (or some similar
 attribute) so that it cannot escape, it would be fine, wouldn't
 it?


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 Davis



 Oct 19 2016



  parent  Namespace <rswhite4 gmail.com>  writes:


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 Davis


Yes, 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



prev sibling  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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:


 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 Davis


 As long as it would be marked with scope (or some similar attribute) so
 that it cannot escape, it would be fine, wouldn't it?


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



 Oct 19 2016



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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



 next sibling parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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:


 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.


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 various

 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



prev sibling  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



prev sibling  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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:

 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.


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.



 Oct 19 2016



prev sibling next sibling parent reply bachmeier <no spam.net>  writes:


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



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 10/18/2016 12:43 PM, bachmeier wrote:

 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.



http://wiki.dlang.org/Language_design_discussions#rvalue_references



 Oct 18 2016



prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 18.10.2016 20:15, ag0aep6g wrote:

 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.


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.



 Oct 18 2016



  parent reply Marco Leise <Marco.Leise gmx.de>  writes:


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



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


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


 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.


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



 Oct 19 2016



  parent  Marco Leise <Marco.Leise gmx.de>  writes:


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



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


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



prev sibling  parent  Namespace <rswhite4 gmail.com>  writes:


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:

 On Tuesday, 18 October 2016 at 09:50:35 UTC, ketmar wrote:

 On Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:

 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


 there is a huge difference between "i can hack around it" 
 and "i can do it".


 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.


 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 Davis


Yep. Therefore my little hack. It works and it isn't such a big 
inconvenience.



 Oct 18 2016



prev sibling  parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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:

 On Tuesday, 18 October 2016 at 09:50:35 UTC, ketmar wrote:

 On Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:

 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


 there is a huge difference between "i can hack around it" and
 "i can do it".


 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.


 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.



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.



 Oct 18 2016



  parent reply Ethan Watson <gooberman gmail.com>  writes:


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



 next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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:


 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.


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



 Oct 19 2016



  parent  Ethan Watson <gooberman gmail.com>  writes:


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



prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 10/19/2016 2:11 AM, Ethan Watson wrote:

 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?"



   void f(ref Vector v);
   void fv(Vector v) { f(v); }

   fv(Vector(10,20,30));

fv gets inlined, so no overhead.



 Oct 19 2016



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


Better:

    void f(ref Vector v);
    void f(Vector v) { f(v); }

    f(Vector(10,20,30));



 Oct 19 2016



  parent reply Ethan Watson <gooberman gmail.com>  writes:


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



 next sibling parent  Namespace <rswhite4 gmail.com>  writes:


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:

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


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



 Oct 20 2016



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/20/2016 06:23 AM, Ethan Watson wrote:

 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.


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,

Andrei



 Oct 20 2016



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 10/20/2016 12:49 PM, Andrei Alexandrescu wrote:

 On 10/20/2016 06:23 AM, Ethan Watson wrote:

 Suitable enough for simple functions. But beyond that becomes
 maintenance hell.


 I agree this workaround has a combinatorial problem.


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.



 Oct 20 2016



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/20/2016 04:57 PM, Walter Bright wrote:

 On 10/20/2016 12:49 PM, Andrei Alexandrescu wrote:

 On 10/20/2016 06:23 AM, Ethan Watson wrote:

 Suitable enough for simple functions. But beyond that becomes
 maintenance hell.


 I agree this workaround has a combinatorial problem.


 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.


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



 Oct 20 2016



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


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



prev sibling  parent  Manu via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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:


 On 10/20/2016 06:23 AM, Ethan Watson wrote:


 Suitable enough for simple functions. But beyond that becomes
 maintenance hell.


 I agree this workaround has a combinatorial problem.


 Yes, Ethan made a good point I hadn't thought of.



Shoot me! ;)



 Oct 20 2016



prev sibling  parent reply Ethan Watson <gooberman gmail.com>  writes:


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



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/21/2016 04:47 AM, Walter Bright wrote:

 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!


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,

Andrei



 Oct 21 2016



prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 21.10.2016 09:56, Ethan Watson wrote:

 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.


Nice! Make sure it is orthogonal to const. :)



 Oct 21 2016



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/21/16 5:39 PM, Timon Gehr wrote:

 On 21.10.2016 09:56, Ethan Watson wrote:

 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.


 Nice! Make sure it is orthogonal to const. :)


It would be great if you participated. Such a DIP needs you. -- Andrei



 Oct 21 2016



  parent reply Timon Gehr <timon.gehr gmx.ch>  writes:


On 22.10.2016 03:10, Andrei Alexandrescu wrote:

 On 10/21/16 5:39 PM, Timon Gehr wrote:

 On 21.10.2016 09:56, Ethan Watson wrote:

 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.


 Nice! Make sure it is orthogonal to const. :)


 It would be great if you participated. Such a DIP needs you. -- Andrei


I'm ready to participate (but I can't invest too much time at the 
moment). Are we going with  rvalue ref?



 Oct 22 2016



  parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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



  parent  bitwise <bitwise.pvt gmail.com>  writes:


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:

 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


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?



 Oct 22 2016



prev sibling  parent reply bitwise <bitwise.pvt gmail.com>  writes:


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:

 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.


Any news on this?



 Oct 28 2016



  parent  bitwise <bitwise.pvt gmail.com>  writes:


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:

 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.


 Any news on this?


Hmm. Why did I expect this?

-_-



 Oct 29 2016



prev sibling  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 10/19/16 5:11 AM, Ethan Watson wrote:

 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?"


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


Andrei



 Oct 19 2016



prev sibling  parent reply Guillaume Piolat <first.last gmail.com>  writes:


On Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:

 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


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.



 Oct 19 2016



  parent reply Namespace <rswhite4 gmail.com>  writes:


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:

 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


 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.


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.



 Oct 19 2016



  parent  Guillaume Piolat <first.last gmail.com>  writes:


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



prev sibling next sibling parent  bitwise <bitwise.pvt gmail.com>  writes:


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



prev sibling  parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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:

 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.


 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.


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 Davis



 Oct 19 2016



  parent reply Nicholas Wilson <iamthewilsonator hotmail.com>  writes:


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



 next sibling parent  ag0aep6g <anonymous example.com>  writes:


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



prev sibling  parent  Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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:

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


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 Davis



 Oct 21 2016