Re: rvalues -> ref (yup... again!)

On 1 April 2018 at 11:55, Timon Gehr via Digitalmars-d wrote: > On 01.04.2018 19:20, Andrei Alexandrescu wrote: >> >> On 3/28/18 7:50 AM, Timon Gehr wrote: >>> >>> "The proposal could be amended to accept mutable ref's depending on the >>> value-judgement balancing

Re: rvalues -> ref (yup... again!)

On 01.04.2018 19:20, Andrei Alexandrescu wrote: On 3/28/18 7:50 AM, Timon Gehr wrote: "The proposal could be amended to accept mutable ref's depending on the value-judgement balancing these 2 use cases. Sticking with const requires no such value judgement to be made at this time, and it's

Re: rvalues -> ref (yup... again!)

On 3/28/18 7:50 AM, Timon Gehr wrote: "The proposal could be amended to accept mutable ref's depending on the value-judgement balancing these 2 use cases. Sticking with const requires no such value judgement to be made at this time, and it's much easier to relax the spec in the future with

Re: rvalues -> ref (yup... again!)

On 3/31/18 9:28 AM, Timon Gehr wrote: On 30.03.2018 11:06, Atila Neves wrote: Right, and I was assuming (perhaps incorrectly) that this existing code was C++, hence me being on board with binding rvalues to const ref there. That must not happen. D const and C++ const don't even mean the

Re: rvalues -> ref (yup... again!)

On 30.03.2018 11:06, Atila Neves wrote: Right, and I was assuming (perhaps incorrectly) that this existing code was C++, hence me being on board with binding rvalues to const ref there. That must not happen. D const and C++ const don't even mean the same thing, and now suddenly you will see

Re: rvalues -> ref (yup... again!)

On 30 March 2018 at 18:52, Walter Bright via Digitalmars-d wrote: > On 3/30/2018 6:03 PM, Manu wrote: >> >> Sadly, I don't think I'll be able to make it to DConf this year... > > > :-( > >> which is probably a reason for rejoice of literally everybody >> attending! :P

Re: rvalues -> ref (yup... again!)

On Friday, March 30, 2018 18:52:38 Walter Bright via Digitalmars-d wrote: > On 3/30/2018 6:03 PM, Manu wrote: > > Sadly, I don't think I'll be able to make it to DConf this year... > : > :-( > : > > which is probably a reason for rejoice of literally everybody > > attending! :P > > You'll be

Re: rvalues -> ref (yup... again!)

On Friday, March 30, 2018 18:03:49 Manu via Digitalmars-d wrote: > On 30 March 2018 at 16:09, Jonathan M Davis via Digitalmars-d > > And honestly, I don't really want to encourage the use of const. It's > > fine if folks use it where it really works, and it's potentially even > > quite valuable

Re: rvalues -> ref (yup... again!)

On 3/30/2018 6:03 PM, Manu wrote: Sadly, I don't think I'll be able to make it to DConf this year... :-( which is probably a reason for rejoice of literally everybody attending! :P You'll be missed. It would be nice to workshop it in person though.

Re: rvalues -> ref (yup... again!)

On 30 March 2018 at 16:09, Jonathan M Davis via Digitalmars-d wrote: > On Friday, March 30, 2018 14:47:06 Manu via Digitalmars-d wrote: >> On 30 March 2018 at 12:24, Jonathan M Davis via Digitalmars-d >> > I want to be able to look at a function signature, see ref

Re: rvalues -> ref (yup... again!)

On Friday, March 30, 2018 14:47:06 Manu via Digitalmars-d wrote: > On 30 March 2018 at 12:24, Jonathan M Davis via Digitalmars-d > > I want to be able to look at a function signature, see ref without other > > qualifiers, and be reasonably certain that the function is supposed to > > be > >

Re: rvalues -> ref (yup... again!)

On 30 March 2018 at 12:24, Jonathan M Davis via Digitalmars-d wrote: > On Friday, March 30, 2018 11:01:23 Manu via Digitalmars-d wrote: >> On 29 March 2018 at 21:08, Jonathan M Davis via Digitalmars-d >> >> wrote: >> > On Thursday, March

Re: rvalues -> ref (yup... again!)

On Friday, March 30, 2018 11:01:23 Manu via Digitalmars-d wrote: > On 29 March 2018 at 21:08, Jonathan M Davis via Digitalmars-d > > wrote: > > On Thursday, March 29, 2018 23:28:54 Nick Sabalausky via Digitalmars-d > > > > wrote: > >> On 03/23/2018 09:06 PM, Jonathan

Re: rvalues -> ref (yup... again!)

On 30 March 2018 at 02:47, Kagamin via Digitalmars-d wrote: > > The only criticism against rvalue references I saw was when the > reference outlives the temporary. That's the only *technical* criticism I've ever heard too. Fortunately, D now has mechanisms for

Re: rvalues -> ref (yup... again!)

On 30 March 2018 at 02:06, Atila Neves via Digitalmars-d wrote: > On Tuesday, 27 March 2018 at 18:14:18 UTC, Manu wrote: >> >> On 27 March 2018 at 00:14, Atila Neves via Digitalmars-d >> wrote: >>> >>> On Monday, 26 March 2018 at 19:24:13

Re: rvalues -> ref (yup... again!)

On 29 March 2018 at 21:08, Jonathan M Davis via Digitalmars-d wrote: > On Thursday, March 29, 2018 23:28:54 Nick Sabalausky via Digitalmars-d > wrote: >> On 03/23/2018 09:06 PM, Jonathan M Davis wrote: >> > My biggest concern in all of this is that I don't want to

Re: rvalues -> ref (yup... again!)

On Wednesday, 28 March 2018 at 16:15:53 UTC, Manu wrote: I discussed that in that document. I'm happy to remove const, but it requires a value judgement on the meaning of non-const in this case. It becomes controversial without const, but I'm personally happy to remove it if you can make The

Re: rvalues -> ref (yup... again!)

On Tuesday, 27 March 2018 at 18:14:18 UTC, Manu wrote: On 27 March 2018 at 00:14, Atila Neves via Digitalmars-d wrote: On Monday, 26 March 2018 at 19:24:13 UTC, Manu wrote: On 26 March 2018 at 07:40, Atila Neves via Digitalmars-d

Re: rvalues -> ref (yup... again!)

On Thursday, March 29, 2018 23:28:54 Nick Sabalausky via Digitalmars-d wrote: > On 03/23/2018 09:06 PM, Jonathan M Davis wrote: > > My biggest concern in all of this is that I don't want to see ref start > > accepting rvalues as has been occasionally discussed. It needs to be > > clear when a

Re: rvalues -> ref (yup... again!)

On 03/24/2018 12:03 AM, Manu wrote: Why aim for "it often works", when we want "it always works"? Forcing const upon people who want to pass rvalues by reference is just not good enough. It is bad language design. I think you need to re-read the whole thread, and understand what we're even

Re: rvalues -> ref (yup... again!)

On 03/23/2018 09:06 PM, Jonathan M Davis wrote: My biggest concern in all of this is that I don't want to see ref start accepting rvalues as has been occasionally discussed. It needs to be clear when a function is accept an argument by ref because it's going to mutate the object and when it's

Re: rvalues -> ref (yup... again!)

On Thursday, 29 March 2018 at 20:22:47 UTC, Dgame wrote: On Thursday, 29 March 2018 at 20:05:48 UTC, Rubn wrote: On Thursday, 29 March 2018 at 19:11:30 UTC, Dgame wrote: Just to be sure it does not got los: You know that you can avoid the temp/copy if you add one method to your struct, yes?

Re: rvalues -> ref (yup... again!)

On Thursday, 29 March 2018 at 20:05:48 UTC, Rubn wrote: On Thursday, 29 March 2018 at 19:11:30 UTC, Dgame wrote: Just to be sure it does not got los: You know that you can avoid the temp/copy if you add one method to your struct, yes? import std.stdio; struct Big { string name;

Re: rvalues -> ref (yup... again!)

On Thursday, 29 March 2018 at 19:11:30 UTC, Dgame wrote: Just to be sure it does not got los: You know that you can avoid the temp/copy if you add one method to your struct, yes? import std.stdio; struct Big { string name; float[1000] values; this(string name) {

Re: rvalues -> ref (yup... again!)

Just to be sure it does not got los: You know that you can avoid the temp/copy if you add one method to your struct, yes? import std.stdio; struct Big { string name; float[1000] values; this(string name) { this.name = name; } @disable this(this); ref

Re: rvalues -> ref (yup... again!)

On Saturday, 24 March 2018 at 17:34:09 UTC, Manu wrote: You mutate a temporary that times out at the end of the statement... your statement is never assigned to anything, and has no effect. That is solved by having the ref function return its argument (so it can be chained): struct S; ref

Re: rvalues -> ref (yup... again!)

On 28.03.2018 20:20, Manu wrote: On 28 March 2018 at 05:22, Timon Gehr via Digitalmars-d wrote: On 27.03.2018 20:14, Manu wrote: That's exactly what I've been saying. For like, 9 years.. It looks like this:

Re: rvalues -> ref (yup... again!)

On 28 March 2018 at 05:38, Timon Gehr via Digitalmars-d wrote: > On 27.03.2018 22:25, Rubn wrote: >> >> >> D already has move semantics, an easy solution to this is to just use >> another keyword. It doesn't have to bind to const ref to get what is >> desired: >> >>

Re: rvalues -> ref (yup... again!)

On 28 March 2018 at 05:22, Timon Gehr via Digitalmars-d wrote: > On 27.03.2018 20:14, Manu wrote: >> >> That's exactly what I've been saying. For like, 9 years.. >> It looks like this: >> >> https://github.com/TurkeyMan/DIPs/blob/ref_args/DIPs/DIP1xxx-rval_to_ref.md

Re: rvalues -> ref (yup... again!)

On 28 Mar. 2018 4:35 am, "Timon Gehr via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: On 27.03.2018 20:14, Manu wrote: > That's exactly what I've been saying. For like, 9 years.. > It looks like this: > https://github.com/TurkeyMan/DIPs/blob/ref_args/DIPs/DIP1xxx > -rval_to_ref.md >

Re: rvalues -> ref (yup... again!)

On 27.03.2018 22:25, Rubn wrote: D already has move semantics, an easy solution to this is to just use another keyword. It doesn't have to bind to const ref to get what is desired: // what was suggested in the original DIP, since scope is being used for something else now void foo(@temp

Re: rvalues -> ref (yup... again!)

On 27.03.2018 20:14, Manu wrote: That's exactly what I've been saying. For like, 9 years.. It looks like this: https://github.com/TurkeyMan/DIPs/blob/ref_args/DIPs/DIP1xxx-rval_to_ref.md (contribution appreciated) "Temporary destruction Destruction of any temporaries occurs naturally at the

Re: rvalues -> ref (yup... again!)

On 28.03.2018 13:34, Timon Gehr wrote: On 27.03.2018 20:14, Manu wrote: That's exactly what I've been saying. For like, 9 years.. It looks like this: https://github.com/TurkeyMan/DIPs/blob/ref_args/DIPs/DIP1xxx-rval_to_ref.md   (contribution appreciated) As far as I can tell, it's

Re: rvalues -> ref (yup... again!)

On 27.03.2018 20:14, Manu wrote: That's exactly what I've been saying. For like, 9 years.. It looks like this: https://github.com/TurkeyMan/DIPs/blob/ref_args/DIPs/DIP1xxx-rval_to_ref.md (contribution appreciated) As far as I can tell, it's completely benign, it just eliminates the annoying

Re: rvalues -> ref (yup... again!)

On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote: By contrast, people will NOT forgive the fact that they have to change: func(f(x), f(y), f(z)); to: T temp = f(x); T temp2 = f(y); T temp3 = f(z); func(temp, temp2, temp3); That's just hideous and in-defensible. A

Re: rvalues -> ref (yup... again!)

On Wednesday, 28 March 2018 at 00:56:29 UTC, kinke wrote: On Tuesday, 27 March 2018 at 23:59:09 UTC, Rubn wrote: Just adding a few writeln it isn't able to remove the function entirely anymore and can't optimize it out. Well writeln() here involves number -> string formatting, GC, I/O,

Re: rvalues -> ref (yup... again!)

On Tuesday, 27 March 2018 at 23:59:09 UTC, Rubn wrote: Just adding a few writeln it isn't able to remove the function entirely anymore and can't optimize it out. Well writeln() here involves number -> string formatting, GC, I/O, template bloat... There are indeed superfluous memcpy's in your

Re: rvalues -> ref (yup... again!)

On Tuesday, 27 March 2018 at 23:35:44 UTC, kinke wrote: On Tuesday, 27 March 2018 at 21:52:25 UTC, Rubn wrote: It happens with LDC too, not sure how it would be able to know to do any kind of optimization like that unless it was able to inline every single function called into one function and

Re: rvalues -> ref (yup... again!)

On Tuesday, 27 March 2018 at 23:35:44 UTC, kinke wrote: On Tuesday, 27 March 2018 at 21:52:25 UTC, Rubn wrote: It happens with LDC too, not sure how it would be able to know to do any kind of optimization like that unless it was able to inline every single function called into one function and

Re: rvalues -> ref (yup... again!)

On Tuesday, 27 March 2018 at 21:52:25 UTC, Rubn wrote: It happens with LDC too, not sure how it would be able to know to do any kind of optimization like that unless it was able to inline every single function called into one function and be able to do optimize it from there. I don't imagine

Re: rvalues -> ref (yup... again!)

On Tue, Mar 27, 2018 at 09:52:25PM +, Rubn via Digitalmars-d wrote: > On Tuesday, 27 March 2018 at 20:38:35 UTC, H. S. Teoh wrote: > > On Tue, Mar 27, 2018 at 08:25:36PM +, Rubn via Digitalmars-d wrote: > > [...] > > > _D7example__T3fooTSQr3FooZQnFNbNiNfQrZv: > > > push rbp > > > mov

Re: rvalues -> ref (yup... again!)

On Tuesday, 27 March 2018 at 20:38:35 UTC, H. S. Teoh wrote: On Tue, Mar 27, 2018 at 08:25:36PM +, Rubn via Digitalmars-d wrote: [...] _D7example__T3fooTSQr3FooZQnFNbNiNfQrZv: push rbp mov rbp, rsp sub rsp, 3104 lea rax, [rbp + 16] lea rdi, [rbp - 2048] lea rcx, [rbp - 1024]

Re: rvalues -> ref (yup... again!)

On Tue, Mar 27, 2018 at 08:25:36PM +, Rubn via Digitalmars-d wrote: [...] > _D7example__T3fooTSQr3FooZQnFNbNiNfQrZv: > push rbp > mov rbp, rsp > sub rsp, 3104 > lea rax, [rbp + 16] > lea rdi, [rbp - 2048] > lea rcx, [rbp - 1024] > mov edx, 1024 > mov rsi, rcx > mov qword ptr

Re: rvalues -> ref (yup... again!)

On Tuesday, 27 March 2018 at 15:50:37 UTC, Atila Neves wrote: It's fine for references to just be references in D. We're not struggling to make references move-able in D, that's not a thing, we already have move semantics. Any extension of this conversation about references into C++

Re: rvalues -> ref (yup... again!)

On Tuesday, 27 March 2018 at 18:14:18 UTC, Manu wrote: That's exactly what I've been saying. For like, 9 years.. It looks like this: https://github.com/TurkeyMan/DIPs/blob/ref_args/DIPs/DIP1xxx-rval_to_ref.md (contribution appreciated) I've followed this thread since it was made as this has

Re: rvalues -> ref (yup... again!)

On Tuesday, 27 March 2018 at 07:33:12 UTC, Atila Neves wrote: On Tuesday, 27 March 2018 at 00:30:24 UTC, Rubn wrote: On Monday, 26 March 2018 at 14:40:03 UTC, Atila Neves wrote: C++ T&& (Rvalue reference) -> D T Not really, in C++ it is an actual reference and you get to choose which

Re: rvalues -> ref (yup... again!)

On 27 March 2018 at 00:14, Atila Neves via Digitalmars-d wrote: > On Monday, 26 March 2018 at 19:24:13 UTC, Manu wrote: >> >> On 26 March 2018 at 07:40, Atila Neves via Digitalmars-d >> wrote: >>> >>> On Friday, 23 March 2018 at 22:01:44

Re: rvalues -> ref (yup... again!)

On Tuesday, 27 March 2018 at 02:41:12 UTC, Manu wrote: He's trying to say that C++ introduced rvalue references because normal references weren't able to allow for move semantics to exist. It's a red-herring. D already has move semantics, they work well, and they're not on trial here. In

Re: rvalues -> ref (yup... again!)

On Tuesday, 27 March 2018 at 00:30:24 UTC, Rubn wrote: On Monday, 26 March 2018 at 14:40:03 UTC, Atila Neves wrote: C++ T&& (Rvalue reference) -> D T Not really, in C++ it is an actual reference and you get to choose which function actually does the move. In D it just does the copy when

Re: rvalues -> ref (yup... again!)

On Monday, 26 March 2018 at 19:24:13 UTC, Manu wrote: On 26 March 2018 at 07:40, Atila Neves via Digitalmars-d wrote: On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote: Forked from the x^^y thread... C++ T&& (forwarding reference) -> D auto ref T C++ T&&

Re: rvalues -> ref (yup... again!)

On 26 March 2018 at 17:30, Rubn via Digitalmars-d wrote: > On Monday, 26 March 2018 at 14:40:03 UTC, Atila Neves wrote: >> >> C++ T&& (Rvalue reference) -> D T > > > Not really, in C++ it is an actual reference and you get to choose which > function actually does the

Re: rvalues -> ref (yup... again!)

On 26 March 2018 at 19:25, Manu wrote: > On 26 March 2018 at 16:21, Rubn via Digitalmars-d > wrote: >> On Monday, 26 March 2018 at 22:48:38 UTC, Walter Bright wrote: >>> >>> On 3/26/2018 12:24 PM, Manu wrote: On 26 March 2018 at 07:40,

Re: rvalues -> ref (yup... again!)

On 26 March 2018 at 16:21, Rubn via Digitalmars-d wrote: > On Monday, 26 March 2018 at 22:48:38 UTC, Walter Bright wrote: >> >> On 3/26/2018 12:24 PM, Manu wrote: >>> >>> On 26 March 2018 at 07:40, Atila Neves via Digitalmars-d C++ const T& -> D T >>> >>>

Re: rvalues -> ref (yup... again!)

On 26 March 2018 at 15:48, Walter Bright via Digitalmars-d wrote: > On 3/26/2018 12:24 PM, Manu wrote: >> >> On 26 March 2018 at 07:40, Atila Neves via Digitalmars-d >>> >>> C++ const T& -> D T >> >> >> Yeah, no... T may be big. Copying a large thing sucks. Memory

Re: rvalues -> ref (yup... again!)

On Monday, 26 March 2018 at 14:40:03 UTC, Atila Neves wrote: C++ T&& (Rvalue reference) -> D T Not really, in C++ it is an actual reference and you get to choose which function actually does the move. In D it just does the copy when passed to the function. So you can't do this in D. void

Re: rvalues -> ref (yup... again!)

On Monday, 26 March 2018 at 22:48:38 UTC, Walter Bright wrote: On 3/26/2018 12:24 PM, Manu wrote: On 26 March 2018 at 07:40, Atila Neves via Digitalmars-d C++ const T& -> D T Yeah, no... T may be big. Copying a large thing sucks. Memory copying is the slowest thing computers can do. As an

Re: rvalues -> ref (yup... again!)

On 3/26/2018 12:24 PM, Manu wrote: On 26 March 2018 at 07:40, Atila Neves via Digitalmars-d C++ const T& -> D T Yeah, no... T may be big. Copying a large thing sucks. Memory copying is the slowest thing computers can do. As an API author, exactly as in C++, you will make a judgement on a

Re: rvalues -> ref (yup... again!)

On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote: Can you please explain these 'weirdities'? What are said "major unintended consequences"? Explain how the situation if implemented would be any different than the workaround? This seems even simpler than the pow thing to me. Rewrite:

Re: rvalues -> ref (yup... again!)

On 26 March 2018 at 11:13, John Colvin via Digitalmars-d wrote: > On Monday, 26 March 2018 at 14:40:03 UTC, Atila Neves wrote: >> >> On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote: >>> >>> Forked from the x^^y thread... >>> >> >> >> There are too many replies

Re: rvalues -> ref (yup... again!)

On 26 March 2018 at 07:40, Atila Neves via Digitalmars-d wrote: > On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote: >> >> Forked from the x^^y thread... >> > > > There are too many replies on this thread, addressing all the comments would > take forever and

Re: rvalues -> ref (yup... again!)

On Monday, 26 March 2018 at 14:40:03 UTC, Atila Neves wrote: On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote: Forked from the x^^y thread... There are too many replies on this thread, addressing all the comments would take forever and pollute the thread itself. So forgive me if I say

Re: rvalues -> ref (yup... again!)

On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote: Forked from the x^^y thread... There are too many replies on this thread, addressing all the comments would take forever and pollute the thread itself. So forgive me if I say something that was covered already by someone else. AFAIK

Re: rvalues -> ref (yup... again!)

On Sunday, 25 March 2018 at 01:43:43 UTC, Jonathan M Davis wrote: On Sunday, March 25, 2018 00:34:38 Rubn via Digitalmars-d wrote: On Saturday, 24 March 2018 at 23:03:36 UTC, John Colvin wrote: > Auto ref allows the unnecessary copy to be avoided for > lvalues and creates a temporary (as part

Re: rvalues -> ref (yup... again!)

On 03/24/2018 03:03 AM, Jonathan M Davis wrote: On Saturday, March 24, 2018 01:37:10 Nick Sabalausky via Digitalmars-d wrote: Why require the callee's author to add boilerplate? Just do it for all ref params that are given an rvalue. Because if the point of the function accepting its

Re: rvalues -> ref (yup... again!)

On Sunday, March 25, 2018 00:34:38 Rubn via Digitalmars-d wrote: > On Saturday, 24 March 2018 at 23:03:36 UTC, John Colvin wrote: > > Auto ref allows the unnecessary copy to be avoided for lvalues > > and creates a temporary (as part of passing the value) for > > rvalues. It has downsides (virtual

Re: rvalues -> ref (yup... again!)

On Saturday, 24 March 2018 at 23:03:36 UTC, John Colvin wrote: Here is a small proof of concept I made to demonstrate how easy it seems to be to use `auto ref` to call a C++ virtual const& function without incurring any more copies than would happen with the same calls from C++. I'm sure it

Re: rvalues -> ref (yup... again!)

On Saturday, 24 March 2018 at 23:03:36 UTC, John Colvin wrote: Auto ref allows the unnecessary copy to be avoided for lvalues and creates a temporary (as part of passing the value) for rvalues. It has downsides (virtual functions and extern(C++), but it does directly address the problem you're

Re: rvalues -> ref (yup... again!)

On Saturday, 24 March 2018 at 17:30:35 UTC, Manu wrote: On 24 March 2018 at 04:57, John Colvin via Digitalmars-d wrote: On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote: Forked from the x^^y thread... On 23 March 2018 at 12:16, Walter Bright via

Re: rvalues -> ref (yup... again!)

On Saturday, 24 March 2018 at 11:57:25 UTC, John Colvin wrote: I understand what you want, but I'm struggling to understand why it's such a huge deal. The reason you want to pass by reference is for performance, to avoid copying the data at the call boundary. It's pretty simple: float

Re: rvalues -> ref (yup... again!)

Here is what I've used if I had to: https://p0nce.github.io/d-idioms/#Rvalue-references:-Understanding-auto-ref-and-then-not-using-it

Re: rvalues -> ref (yup... again!)

On 24 March 2018 at 07:56, kinke via Digitalmars-d wrote: > On Saturday, 24 March 2018 at 13:49:13 UTC, Timon Gehr wrote: >> >> What I'm saying is that I don't really buy Jonathan's argument. Basically, >> you should just pass the correct arguments to functions, as

Re: rvalues -> ref (yup... again!)

On 24 March 2018 at 06:49, Timon Gehr via Digitalmars-d wrote: > On 24.03.2018 05:03, Manu wrote: >> >> I have no idea what this paragraph means... can you elaborate further >> what you're talking about? > > This works: > > struct S{ > int x; > void inc(){ >

Re: rvalues -> ref (yup... again!)

On 24 March 2018 at 04:57, John Colvin via Digitalmars-d wrote: > On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote: >> >> Forked from the x^^y thread... >> >> On 23 March 2018 at 12:16, Walter Bright via Digitalmars-d >> wrote: >>>

Re: rvalues -> ref (yup... again!)

Am Sat, 24 Mar 2018 17:10:53 + schrieb Johannes Pfau: > Am Sat, 24 Mar 2018 01:04:00 -0600 schrieb Jonathan M Davis: > >> As it stands, because a function can't accept rvalues by ref, it's >> usually reasonable to assume that a function accepts its argument by >> ref because it's mutating

Re: rvalues -> ref (yup... again!)

Am Sat, 24 Mar 2018 01:04:00 -0600 schrieb Jonathan M Davis: > As it stands, because a function can't accept rvalues by ref, it's > usually reasonable to assume that a function accepts its argument by ref > because it's mutating that argument rather than simply because it's > trying to avoid a

Re: rvalues -> ref (yup... again!)

On Saturday, 24 March 2018 at 15:36:14 UTC, Timon Gehr wrote: On 24.03.2018 15:56, kinke wrote: I agree, but restricting it to const ref would be enough for almost all of my use cases. The MS C++ compiler just emits a warning when binding an rvalue to a mutable ref ('nonstandard extension

Re: rvalues -> ref (yup... again!)

On 24.03.2018 15:56, kinke wrote: On Saturday, 24 March 2018 at 13:49:13 UTC, Timon Gehr wrote: What I'm saying is that I don't really buy Jonathan's argument. Basically, you should just pass the correct arguments to functions, as you always need to do. If you cannot use the result of some

Re: rvalues -> ref (yup... again!)

On Saturday, 24 March 2018 at 13:49:13 UTC, Timon Gehr wrote: What I'm saying is that I don't really buy Jonathan's argument. Basically, you should just pass the correct arguments to functions, as you always need to do. If you cannot use the result of some mutation that you need to use, you

Re: rvalues -> ref (yup... again!)

On 24.03.2018 05:03, Manu wrote: On 23 March 2018 at 20:17, Timon Gehr via Digitalmars-d wrote: On 24.03.2018 02:16, Manu wrote: This is an interesting point, but I don't think it changes the balance in any way. Thinking of the majority of my anecdotal cases, I

Re: rvalues -> ref (yup... again!)

On Saturday, 24 March 2018 at 11:57:25 UTC, John Colvin wrote: I understand what you want, but I'm struggling to understand why it's such a huge deal. ... What I would do in D currently to get the same performance and API: void foo(float[32] v) { foo(v); } void foo(ref float[32] v) { ... }

Re: rvalues -> ref (yup... again!)

On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote: Forked from the x^^y thread... On 23 March 2018 at 12:16, Walter Bright via Digitalmars-d wrote: On 3/23/2018 11:09 AM, Manu wrote: [...] Rvalue references are not trivial and can have major unintended

Re: rvalues -> ref (yup... again!)

On 24 March 2018 at 00:04, Jonathan M Davis via Digitalmars-d wrote: > On Saturday, March 24, 2018 01:37:10 Nick Sabalausky via Digitalmars-d > wrote: >> On 03/23/2018 07:46 PM, Jonathan M Davis wrote: >> > On Friday, March 23, 2018 22:44:35 Nick Sabalausky via

Re: rvalues -> ref (yup... again!)

On Saturday, March 24, 2018 01:37:10 Nick Sabalausky via Digitalmars-d wrote: > On 03/23/2018 07:46 PM, Jonathan M Davis wrote: > > On Friday, March 23, 2018 22:44:35 Nick Sabalausky via Digitalmars-d wrote: > >> It never made any sense to me that there could be any problem > >> with the

Re: rvalues -> ref (yup... again!)

On 03/23/2018 07:46 PM, Jonathan M Davis wrote: On Friday, March 23, 2018 22:44:35 Nick Sabalausky via Digitalmars-d wrote: It never made any sense to me that there could be any problem with the compiler automatically creating a temporary hidden lvalue so a ref could be taken. If there IS any

Re: rvalues -> ref (yup... again!)

On 23 March 2018 at 20:19, Timon Gehr via Digitalmars-d wrote: > On 24.03.2018 04:14, Manu wrote: >> >> On 23 March 2018 at 20:03, Timon Gehr via Digitalmars-d >> wrote: >>> >>> On 24.03.2018 01:35, Manu wrote: Okay, let's

Re: rvalues -> ref (yup... again!)

On 23 March 2018 at 20:17, Timon Gehr via Digitalmars-d wrote: > On 24.03.2018 02:16, Manu wrote: >> >> This is an interesting point, but I don't think it changes the balance >> in any way. Thinking of the majority of my anecdotal cases, I don't >> think it would be a

Re: rvalues -> ref (yup... again!)

On 24.03.2018 04:14, Manu wrote: On 23 March 2018 at 20:03, Timon Gehr via Digitalmars-d wrote: On 24.03.2018 01:35, Manu wrote: Okay, let's read 'const ref' every time I say 'ref'. I thought that would be fairly safe to assume. Sorry! Absolutely not. It makes

Re: rvalues -> ref (yup... again!)

On 24.03.2018 02:16, Manu wrote: This is an interesting point, but I don't think it changes the balance in any way. Thinking of the majority of my anecdotal cases, I don't think it would be a problem. Something complex enough for const to be a problem likely doesn't conform to this pattern.

Re: rvalues -> ref (yup... again!)

On 23 March 2018 at 20:03, Timon Gehr via Digitalmars-d wrote: > On 24.03.2018 01:35, Manu wrote: >> >> Okay, let's read 'const ref' every time I say 'ref'. I thought that >> would be fairly safe to assume. Sorry! > > > Absolutely not. It makes absolutely no sense to

Re: rvalues -> ref (yup... again!)

On 24.03.2018 01:35, Manu wrote: Okay, let's read 'const ref' every time I say 'ref'. I thought that would be fairly safe to assume. Sorry! Absolutely not. It makes absolutely no sense to restrict rvalue references to const objects. (Recall that const is transitive and actually prevents

Re: rvalues -> ref (yup... again!)

On 23 March 2018 at 18:06, Jonathan M Davis via Digitalmars-d wrote: > On Friday, March 23, 2018 17:20:09 Manu via Digitalmars-d wrote: >> On 23 March 2018 at 16:58, Jonathan M Davis via Digitalmars-d >> >> wrote: >> > On Friday, March

Re: rvalues -> ref (yup... again!)

On 23 March 2018 at 17:58, Jonathan M Davis via Digitalmars-d wrote: > On Friday, March 23, 2018 17:35:11 Manu via Digitalmars-d wrote: >> > but that by itself isn't >> > enough if you want it to be clear whether a function is supposed to be >> > mutating the argument

Re: rvalues -> ref (yup... again!)

On Friday, March 23, 2018 17:20:09 Manu via Digitalmars-d wrote: > On 23 March 2018 at 16:58, Jonathan M Davis via Digitalmars-d > > wrote: > > On Friday, March 23, 2018 23:35:29 MattCoder via Digitalmars-d wrote: > >> Well, to be honest I still can't understand why

Re: rvalues -> ref (yup... again!)

On Friday, March 23, 2018 17:35:11 Manu via Digitalmars-d wrote: > > but that by itself isn't > > enough if you want it to be clear whether a function is supposed to be > > mutating the argument > > Functions that receive const args make it pretty clear that they don't > intend to mutate the arg.

Re: rvalues -> ref (yup... again!)

On 23 March 2018 at 17:48, MattCoder via Digitalmars-d wrote: > > Question: > > In C++ the signature of the function which will receive the references like > in this case, need to be "const ref" parameters, right? - If yes, then since > it's const ref parameter, will

Re: rvalues -> ref (yup... again!)

On Friday, 23 March 2018 at 23:58:05 UTC, Jonathan M Davis wrote: On Friday, March 23, 2018 23:35:29 MattCoder via Digitalmars-d wrote: Well, to be honest I still can't understand why would you want to pass a RValue as reference. Well, it's frequently the case that you don't want to copy an

Re: rvalues -> ref (yup... again!)

On 23 March 2018 at 16:46, Jonathan M Davis via Digitalmars-d wrote: > On Friday, March 23, 2018 22:44:35 Nick Sabalausky via Digitalmars-d wrote: >> It never made any sense to me that there could be any problem >> with the compiler automatically creating a temporary

Re: rvalues -> ref (yup... again!)

On 23 March 2018 at 16:58, Jonathan M Davis via Digitalmars-d wrote: > On Friday, March 23, 2018 23:35:29 MattCoder via Digitalmars-d wrote: >> Well, to be honest I still can't understand why would you want to >> pass a RValue as reference. > > Well, it's frequently

Re: rvalues -> ref (yup... again!)

On Friday, March 23, 2018 23:35:29 MattCoder via Digitalmars-d wrote: > Well, to be honest I still can't understand why would you want to > pass a RValue as reference. Well, it's frequently the case that you don't want to copy an object if you don't have to - especially in the gaming world, where

Re: rvalues -> ref (yup... again!)

On Friday, March 23, 2018 22:44:35 Nick Sabalausky via Digitalmars-d wrote: > It never made any sense to me that there could be any problem > with the compiler automatically creating a temporary hidden > lvalue so a ref could be taken. If there IS any problem, I can > only imagine it would be

  1   2   >