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 these 2 use cases. Sticking with
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
much
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 emer
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 sam
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
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
>
>
> You'll be missed.
Than
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 missed
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 the
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.
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 without other
>> > qualifiers, an
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
> > mutatin
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 29, 2018 23:28:54 Nick Sabalausky via Digitalmars-d
>> >
>
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 M Davis wrote:
> >> > My bigg
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 preventing that; D's @safety
story w
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 UTC, Manu wrote:
On 26 March 2018 at 07:40,
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 see ref start
>> > accepting rva
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 ar
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
wrote:
On Friday, 23 March 2018 at 22:01:44 UTC, Manu 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 see ref start
> > accepting rvalues as has been occasionally discussed. It needs to be
> > clear when a fun
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 talk
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 ac
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?
-
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;
f
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) {
this.
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
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 S
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:
https://github.com/TurkeyMan/DIPs/blob/ref_args/DIPs/DIP1xxx-rval_to_ref.md
(contr
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:
>>
>> // what was suggested in the or
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
>> (contribution appreciated)
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
> (co
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
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 e
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 completely
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 ed
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 bet
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, templa
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
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
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
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 th
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 rb
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]
mo
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 [
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++
rvalue-ref
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 be
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 functio
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 UTC, Manu wrote:
Forked from the x^^y thread
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 C++
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 pass
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&& (Rvalue reference) -> D T
C++ c
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 move. In D it just does the co
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, Atila Neves via Digitalmars-d
>
> C++ const
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
>>>
>>>
>>> Yeah, no... T may be big. Co
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 copying
>> is the slowest thing c
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 ba
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 A
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
case-
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:
f
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 on this thread, addressing all
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 pollute the thread itself. So forgi
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 s
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 be
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 o
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 argument
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
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 cou
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
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 Digitalmars-d
wrote:
On 3/23/2018 11:0
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 foo()
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
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 you always need
>> to do. If you
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(){
> this.x++; // note: 'thi
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:
>>>
>>> On 3/23/2018 11:09 AM, Manu wrote:
[...]
>
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 tha
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 cop
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 used
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 muta
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 wil
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 don't
think it would be a probl
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) { ... }
o
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 consequences. They're a rather u
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 Digitalmars-d
> wrote:
>> >> It nev
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 compile
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 pr
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 read 'const ref' every time I say 'ref'. I thought that
>>>
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 problem.
>> Something complex
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 absolutely no sense to restri
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.
Why
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 restrict rvalue references
> t
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 mutat
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 23, 2018 23:35:29 MattCoder via Digitalmars-d wrote:
>> >> We
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
>>
>> Functions that receive
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 would you want to
> >> pass a R
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.
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 not change the value passed, e
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
o
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 hidden
>> lvalue so a ref coul
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 the case that you don't want to
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
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 sympt
1 - 100 of 103 matches
Mail list logo
