Re: Getter an lvalue and cannot be modified

2018-05-29 Thread Steven Schveighoffer via Digitalmars-d-learn
On 5/27/18 5:23 AM, IntegratedDimensions wrote: C[] c; @property C[] get() { return c; } get ~= something; errors out, yet auto q = get; q ~= something; is fine. It's "fine", but not doing what you may expect. This appends an element to q, but does nothing to c. While an array is not

Re: Getter an lvalue and cannot be modified

2018-05-27 Thread Mike Franklin via Digitalmars-d-learn
On Sunday, 27 May 2018 at 23:21:05 UTC, IntegratedDimensions wrote: I came across a few posts mentioning this after the fact. It's been this way since at least 2012 so... It's now may so not sure how much longer we'll have to wait. That pull seems to have stalled. So close but so far away ;/

Re: Getter an lvalue and cannot be modified

2018-05-27 Thread IntegratedDimensions via Digitalmars-d-learn
On Sunday, 27 May 2018 at 09:28:36 UTC, Mike Franklin wrote: On Sunday, 27 May 2018 at 09:23:09 UTC, IntegratedDimensions wrote: C[] c; @property C[] get() { return c; } get ~= something; errors out, yet auto q = get; q ~= something; is fine. Why is D thinking that ~= is being applied to

Re: Getter an lvalue and cannot be modified

2018-05-27 Thread Mike Franklin via Digitalmars-d-learn
On Sunday, 27 May 2018 at 09:23:09 UTC, IntegratedDimensions wrote: C[] c; @property C[] get() { return c; } get ~= something; errors out, yet auto q = get; q ~= something; is fine. Why is D thinking that ~= is being applied to get, the function, rather than what it returns? Also When

Re: Overloading for lvalue and rvalue.

2017-06-12 Thread Jonathan M Davis via Digitalmars-d-learn
On Monday, June 12, 2017 20:40:52 Balagopal Komarath via Digitalmars-d-learn wrote: > Is there a way to avoid the following combinatorial explosion of > overloaded functions when overloading for lvalue and rvalue > arguments? The following may be a bad example because int is > cheap to copy. So

Re: not an lvalue

2011-05-02 Thread Steven Schveighoffer
On Sun, 01 May 2011 09:30:34 -0400, CrypticMetaphor crypticmetapho...@gmail.com wrote: Hi, I've been away from D for a while, but now I'm back and I'm stuck with an compile time error. I've got a Matrix33 class and a Vector3 class, but something is wrong with the way I return my Vector3

Re: not an lvalue

2011-05-01 Thread Peter Alexander
On 1/05/11 2:30 PM, CrypticMetaphor wrote: Hi, I've been away from D for a while, but now I'm back and I'm stuck with an compile time error. I've got a Matrix33 class and a Vector3 class, but something is wrong with the way I return my Vector3 in my matrix class: If I do this I get an error:

Re: not an lvalue

2011-05-01 Thread Dmitry Olshansky
On 01.05.2011 17:30, CrypticMetaphor wrote: Hi, I've been away from D for a while, but now I'm back and I'm stuck with an compile time error. I've got a Matrix33 class and a Vector3 class, but something is wrong with the way I return my Vector3 in my matrix class: If I do this I get an

Re: not an lvalue

2011-05-01 Thread CrypticMetaphor
On 5/1/2011 3:53 PM, Dmitry Olshansky wrote: Ehm.. Well, first things first: you shouldn't use classes for lightweight plain data things like vectors. There are structs for that. In general, structs are value-like objects living on the stack while classes are reference-like objects living on

Re: not an lvalue

2011-05-01 Thread Peter Alexander
On 1/05/11 2:53 PM, Dmitry Olshansky wrote: Ehm.. Well, first things first: you shouldn't use classes for lightweight plain data things like vectors. There are structs for that. In general, structs are value-like objects living on the stack while classes are reference-like objects living on the

Re: not an lvalue

2011-05-01 Thread Dmitry Olshansky
On 01.05.2011 19:31, Peter Alexander wrote: On 1/05/11 2:53 PM, Dmitry Olshansky wrote: Ehm.. Well, first things first: you shouldn't use classes for lightweight plain data things like vectors. There are structs for that. In general, structs are value-like objects living on the stack while