On Thursday, 9 November 2023 at 10:14:46 UTC, Bienlein wrote:
On Thursday, 9 November 2023 at 09:40:47 UTC, Bienlein wrote:
On Wednesday, 8 November 2023 at 16:47:02 UTC, Paul Backus
wrote:
On Wednesday, 8 November 2023 at 16:30:49 UTC, Bienlein wrote:
...
The actual problem here is that you
On Thursday, 9 November 2023 at 09:40:47 UTC, Bienlein wrote:
On Wednesday, 8 November 2023 at 16:47:02 UTC, Paul Backus
wrote:
On Wednesday, 8 November 2023 at 16:30:49 UTC, Bienlein wrote:
...
The actual problem here is that you can't take the address of
a template without instantiating it
On Wednesday, 8 November 2023 at 16:47:02 UTC, Paul Backus wrote:
On Wednesday, 8 November 2023 at 16:30:49 UTC, Bienlein wrote:
...
The actual problem here is that you can't take the address of a
template without instantiating it first. To make your example
work, replace `` with `!int`, like
On Wednesday, 8 November 2023 at 16:30:49 UTC, Bienlein wrote:
Hello,
I get the error "`addToBiz(T)(Biz!T biz)` is not an lvalue and
cannot be modified" when compiling the code below. Can't find a
way how to do it right. Am a D newbie and would appreciate some
help.
[...]
s
Hello,
I get the error "`addToBiz(T)(Biz!T biz)` is not an lvalue and
cannot be modified" when compiling the code below. Can't find a
way how to do it right. Am a D newbie and would appreciate some
help.
Thank you, Bienlein
class Biz(T) {
private T value;
th
On Sunday, 20 September 2020 at 17:08:49 UTC, realhet wrote:
On Sunday, 20 September 2020 at 16:18:19 UTC, Steven
Schveighoffer wrote:
On 9/20/20 11:52 AM, realhet wrote:
On Sunday, 20 September 2020 at 14:54:09 UTC, Steven
Schveighoffer wrote:
On 9/20/20 9:30 AM, realhet wrote:
Yeah, I
On Sunday, 20 September 2020 at 16:18:19 UTC, Steven
Schveighoffer wrote:
On 9/20/20 11:52 AM, realhet wrote:
On Sunday, 20 September 2020 at 14:54:09 UTC, Steven
Schveighoffer wrote:
On 9/20/20 9:30 AM, realhet wrote:
Yeah, I think this might work.
-Steve
That would be a 3rd category out
On 9/20/20 11:52 AM, realhet wrote:
On Sunday, 20 September 2020 at 14:54:09 UTC, Steven Schveighoffer wrote:
On 9/20/20 9:30 AM, realhet wrote:
ref inout(int) x() inout { return array[0]; }
This doesn't work when I type:
v.x++;
It should, as long as v is mutable.
I want to make a similar
)
res[i] = mixin(ch); // ch can be one of xyzw or rgba or
stpq or 0 or 1.
// just mix it in using the already
created lvalue swizzles of (integer consts 01)
return res;
}
}
I also have an idea that if I use capital letters, it shoud mean
negative
;
a.yzw = b.xzy;
On the left there is a contiguous area of the vector a. It just
starts form the 1th element, not form the 0th: a[1..4]. It could
be work as an lvalue.
On the right there is a non-contiguous swizzle: [b.x, b.z, b.y].
But because it is 3 element wide, it can be assigned
On 9/20/20 9:30 AM, realhet wrote:
Hi,
struct S{
int[2] array;
ref x() { return array[0]; }
auto x() const { return array[0]; }
}
If there a way to write the function 'x' into one function, not 2
overloads.
I tried auto/const/ref mindlessly :D, also remembered 'inout', but
On Sunday, 20 September 2020 at 13:30:36 UTC, realhet wrote:
Hi,
More specifically:
struct S{
int[2] array;
ref swizzle(string code)(){
static if(code=="x") return array[0];
else static if(code=="y") return array[1];
else static assert("Unhandled");
}
Hi,
struct S{
int[2] array;
ref x() { return array[0]; }
auto x() const { return array[0]; }
}
If there a way to write the function 'x' into one function, not 2
overloads.
I tried auto/const/ref mindlessly :D, also remembered 'inout',
but obviously those weren't solve the
s, it says "get() is not an lvalue and cannot be
modified", which seems to indicate that the expression get() (meaning
what it returns) is not an lvalue. While it's a bit ambiguous in this
case, a more complicated expression would be self-explanatory. Maybe the
error messag
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 ;/
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
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
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 I converted a field in to a property, an AA, it is returning
null
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
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 assume a large datatype instead of int.
import std.stdio;
void foo(in ref int a, in ref
On Friday, 28 April 2017 at 05:21:26 UTC, ag0aep6g wrote:
Instead of removing `in`/`const` from the ref overload, you can
also add it to the non-ref overload. Again, the overloads will
have the same match level ("match with conversion to const"),
and the ref version will win.
It works. I
On 04/28/2017 06:46 AM, ANtlord wrote:
struct MyStruct
{
@disable this(this);
int a;
}
void process(MyStruct obj) {
writeln("incoming rvalue");
}
void process(in ref MyStruct obj) {
writeln("incoming lvalue");
}
void main()
{
MyStruct obj = {a:
On Friday, 28 April 2017 at 04:46:00 UTC, ANtlord wrote:
Does make sense for me because it is more obvious in client
code, but I want to understand reason of error pointed above.
Typo fix.
It makes sense for me*
Hello! Short time ago I've met strange thing at least for me. I
have a non-copyable structure and two methods for it with same
name. I mean that I use function overloading.
First method takes rvalue of this structure. Second method takes
constant lvalue structure. But when I try to use
On Wednesday, 25 January 2017 at 21:04:50 UTC, Adam D. Ruppe
wrote:
On Wednesday, 25 January 2017 at 20:42:52 UTC, bitwise wrote:
Is it not possible to return a ref from an inout function?
It isn't the inout that's getting you, it is the const object
in main().
const(List!int) c;
Make
On Wednesday, 25 January 2017 at 20:42:52 UTC, bitwise wrote:
Is it not possible to return a ref from an inout function?
It isn't the inout that's getting you, it is the const object in
main().
const(List!int) c;
Make that mutable and it works. Why? Cuz the `C list` in the
iterator
Compiling the code below gives these errors:
main.d(92): Error:
cast(inout(int))this.list.data[cast(uint)(this.pos + i)] is not
an lvalue
main.d(101): Error: template instance
main.Iterator!(const(List!int)) error instantiating
main.d(108): instantiated from here: first!(const(List!int
On Thursday, 15 December 2016 at 15:29:13 UTC, Adam D. Ruppe
wrote:
General rule of thumb: if you are refing for performance,
actually check it before and after first, ref isn't always
faster.
But D doesn't make this easy, as it disallows rvalues to be
passed by ref. It's a very common
On Thursday, 15 December 2016 at 14:05:08 UTC, Andrey wrote:
In D, probably, I could write something like this:
void open(in string fileName) {...}
Yes, though remember that `in` does have a specific meaning (even
though the compiler rarely enforces it): it means you promise not
to modify
On Thursday, 15 December 2016 at 13:59:05 UTC, Andrey wrote:
Thanks it works, but where should I use the ref?
Only when you need it, break the habit of using it everywhere.
If it is a value type and you want modifications to the variable
itself be seen outside the function, use it:
void
On Tuesday, 13 December 2016 at 16:23:16 UTC, Adam D. Ruppe wrote:
On Tuesday, 13 December 2016 at 15:09:10 UTC, Andrey wrote:
void moveTo(ref Parameter parent) {
You probably don't want the `ref` there, nor likely on any
other method definitions (especially check removeValue).
In D,
On Tuesday, 13 December 2016 at 16:23:16 UTC, Adam D. Ruppe wrote:
On Tuesday, 13 December 2016 at 15:09:10 UTC, Andrey wrote:
void moveTo(ref Parameter parent) {
You probably don't want the `ref` there, nor likely on any
other method definitions (especially check removeValue).
Thanks it
On Tuesday, 13 December 2016 at 17:52:21 UTC, Adam D. Ruppe wrote:
On Tuesday, 13 December 2016 at 17:26:28 UTC, kink wrote:
Assuming `Parameter` is a class and not a struct, yes.
Even if it is a struct, ref wouldn't make a difference here
because the variable is assigned to a member, which
On Tuesday, 13 December 2016 at 17:26:28 UTC, kink wrote:
Assuming `Parameter` is a class and not a struct, yes.
Even if it is a struct, ref wouldn't make a difference here
because the variable is assigned to a member, which means ref
would get lost.
On Tuesday, 13 December 2016 at 16:23:16 UTC, Adam D. Ruppe wrote:
On Tuesday, 13 December 2016 at 15:09:10 UTC, Andrey wrote:
void moveTo(ref Parameter parent) {
You probably don't want the `ref` there, nor likely on any
other method definitions (especially check removeValue).
Assuming
On Tuesday, 13 December 2016 at 15:09:10 UTC, Andrey wrote:
void moveTo(ref Parameter parent) {
You probably don't want the `ref` there, nor likely on any other
method definitions (especially check removeValue).
Hello, I'm newbie in D. I'm trying to rewrite my project from C++
and now I get strange warning:
src/e2ml/node.d(23,22): Deprecation: this is not an lvalue
As I write the following code
void moveTo(ref Parameter parent) {
this.p_parent.removeValue(this);
this.p_parent = parent
On 02/01/16 20:47, Meta via Digitalmars-d-learn wrote:
> On Monday, 1 February 2016 at 18:28:05 UTC, Artur Skawina wrote:
>> On 01/31/16 23:11, Steven Schveighoffer via Digitalmars-d-learn wrote:
>>> Thanks! I was surprised this is not straightforward.
>>
>>enum isLvalue(alias A) =
On 02/01/16 21:42, Artur Skawina wrote:
> On 02/01/16 20:47, Meta via Digitalmars-d-learn wrote:
>> That looks much nicer. It still needs work to properly handle functions with
>> non-empty argument lists.
>
> Then it gets a bit long for a one-liner ;)
>
>enum isLvalue(A...) =
On Monday, 1 February 2016 at 18:28:05 UTC, Artur Skawina wrote:
On 01/31/16 23:11, Steven Schveighoffer via Digitalmars-d-learn
wrote:
Thanks! I was surprised this is not straightforward.
enum isLvalue(alias A) = is(typeof((ref _){}(A)));
artur
That looks much nicer. It still needs
On 2/1/16 2:47 PM, Meta wrote:
On Monday, 1 February 2016 at 18:28:05 UTC, Artur Skawina wrote:
On 01/31/16 23:11, Steven Schveighoffer via Digitalmars-d-learn wrote:
Thanks! I was surprised this is not straightforward.
enum isLvalue(alias A) = is(typeof((ref _){}(A)));
artur
That
On Monday, 1 February 2016 at 20:53:35 UTC, Artur Skawina wrote:
On 02/01/16 21:42, Artur Skawina wrote:
On 02/01/16 20:47, Meta via Digitalmars-d-learn wrote:
That looks much nicer. It still needs work to properly handle
functions with non-empty argument lists.
Then it gets a bit long for a
On Sunday, 31 January 2016 at 22:11:45 UTC, Steven Schveighoffer
wrote:
Thanks! I was surprised this is not straightforward.
-Steve
For function return values, at least, you can do this:
import std.traits, std.stdio;
int foo()
{
return 0;
}
ref int bar()
{
static int x = 0;
12)
Thanks. In my case, I need to treat fields and properties that return by
ref the same way.
What I wanted essentially was a template constraint that says "this type
has a member named foo, and t.foo is an lvalue"
-Steve
On 1/31/16 5:12 PM, Meta wrote:
On Sunday, 31 January 2016 at 22:11:45 UTC, Steven Schveighoffer wrote:
On 1/31/16 4:48 PM, Meta wrote:
This seems to do the trick, although I haven't extensively tested it.
There's probably a simpler way but this is the first thing I could come
up with that
On Monday, 1 February 2016 at 22:32:26 UTC, Steven Schveighoffer
wrote:
What I wanted essentially was a template constraint that says
"this type has a member named foo, and t.foo is an lvalue"
-Steve
Like this?
template hasLValProperty(T, string property) {
enum hasLV
On 01/31/16 23:11, Steven Schveighoffer via Digitalmars-d-learn wrote:
> Thanks! I was surprised this is not straightforward.
enum isLvalue(alias A) = is(typeof((ref _){}(A)));
artur
On 1/31/16 4:48 PM, Meta wrote:
This seems to do the trick, although I haven't extensively tested it.
There's probably a simpler way but this is the first thing I could come
up with that works.
Thanks! I was surprised this is not straightforward.
-Steve
On Sunday, 31 January 2016 at 22:11:45 UTC, Steven Schveighoffer
wrote:
On 1/31/16 4:48 PM, Meta wrote:
This seems to do the trick, although I haven't extensively
tested it.
There's probably a simpler way but this is the first thing I
could come
up with that works.
Thanks! I was
struct S
{
int x;
ref int y() { return x; }
int z() { return 1; }
}
What can I use, given S, to determine that x and y yield lvalues, while
z yields an rvalue?
I was expecting something like isLvalue somewhere, but cannot find it.
__traits(isRef, ...) doesn't work.
-Steve
On Sunday, 31 January 2016 at 20:49:43 UTC, Steven Schveighoffer
wrote:
struct S
{
int x;
ref int y() { return x; }
int z() { return 1; }
}
What can I use, given S, to determine that x and y yield
lvalues, while z yields an rvalue?
I was expecting something like isLvalue somewhere, but
On 01/31/2016 01:48 PM, Meta wrote:
This seems to do the trick, although I haven't extensively tested it.
There is hasLvalueElements() as well. Its implementation my be similar
or give other ideas:
https://dlang.org/phobos/std_range_primitives.html#hasLvalueElements
Ali
On Monday, 1 February 2016 at 00:20:00 UTC, Ali Çehreli wrote:
On 01/31/2016 01:48 PM, Meta wrote:
This seems to do the trick, although I haven't extensively
tested it.
There is hasLvalueElements() as well. Its implementation my be
similar or give other ideas:
The code below fails to compile due to the last line. I was
hoping casting away immutable would allow the call to foo. I
think it is not accepted because of the rval to ref issue. If
that is the case, how can foo be called by casting?
I'm not a fan of casting but I'm finding cases where it is
On Wednesday, 16 October 2013 at 17:05:25 UTC, Daniel Davidson
wrote:
import std.conv;
struct T {
int[] i;
string[string] ss;
}
void foo(ref T t) {
}
void main() {
T t1;
auto t2 = immutable T();
foo(t1);
foo(cast()t2);
}
It works as it should. Make a mutable copy of t2 and pass
On Wednesday, 16 October 2013 at 17:16:39 UTC, Dicebot wrote:
It works as it should. Make a mutable copy of t2 and pass it.
Or make foo() accept const. I can't imagine a single legitimate
use case for destroying type system in a way you want.
How do you propose to make a mutable copy
On Wednesday, 16 October 2013 at 17:50:48 UTC, Daniel Davidson
wrote:
On Wednesday, 16 October 2013 at 17:16:39 UTC, Dicebot wrote:
It works as it should. Make a mutable copy of t2 and pass it.
Or make foo() accept const. I can't imagine a single
legitimate use case for destroying type
struct S {
R r;
this(ref immutable(T) t) immutable {
r.tupleof = t.tupleof;
}
}
?
On Wednesday, 16 October 2013 at 17:05:25 UTC, Daniel Davidson
wrote:
The code below fails to compile due to the last line. I was
hoping casting away immutable would allow the call to foo. I
think it is not accepted because of the rval to ref issue. If
that is the case, how can foo be called
On Wednesday, 16 October 2013 at 17:58:41 UTC, Dicebot wrote:
On Wednesday, 16 October 2013 at 17:50:48 UTC, Daniel Davidson
wrote:
On Wednesday, 16 October 2013 at 17:16:39 UTC, Dicebot wrote:
It works as it should. Make a mutable copy of t2 and pass it.
Or make foo() accept const. I can't
On Wednesday, 16 October 2013 at 17:55:56 UTC, Dicebot wrote:
struct S {
R r;
this(ref immutable(T) t) immutable {
r.tupleof = t.tupleof;
}
}
?
Thanks. It is cute - but not so helpful. The example stands. I
*need* to call a createRFromT.
Their shapes are the same in this simple
On Wednesday, 16 October 2013 at 18:09:55 UTC, Maxim Fomin wrote:
On Wednesday, 16 October 2013 at 17:05:25 UTC, Daniel Davidson
wrote:
The code below fails to compile due to the last line. I was
hoping casting away immutable would allow the call to foo. I
think it is not accepted because of
On Wednesday, 16 October 2013 at 18:14:22 UTC, Daniel Davidson
wrote:
I agree with the sentiment. But as it stands I think a copy
should not be necessary. I could make a local mutable R, pass
it to createRFromT to get it initialized and then copy it back
somehow to the member variable r. That
On Wednesday, 16 October 2013 at 17:50:48 UTC, Daniel Davidson
wrote:
How do you propose to make a mutable copy *generically*?
You can't. Let alone generically.
If I give you an immutable int* p, how do you copy it to int*
p ?
On Wednesday, 16 October 2013 at 18:11:48 UTC, Daniel Davidson
On Wednesday, 16 October 2013 at 19:49:25 UTC, monarch_dodra
wrote:
On Wednesday, 16 October 2013 at 17:50:48 UTC, Daniel Davidson
wrote:
How do you propose to make a mutable copy *generically*?
You can't. Let alone generically.
If I give you an immutable int* p, how do you copy it to
int*
On Wednesday, 16 October 2013 at 19:49:25 UTC, monarch_dodra
wrote:
On Wednesday, 16 October 2013 at 17:50:48 UTC, Daniel Davidson
wrote:
How do you propose to make a mutable copy *generically*?
You can't. Let alone generically.
If I give you an immutable int* p, how do you copy it to
int*
void main() {
foo!();
}
template foo( ) {
void foo() {
auto a = (foo);
}
}
dmd from master (a few days ago) gives:
Error: foo()() is not an lvalue
wut?
Ellery Newcomer:
dmd from master (a few days ago) gives:
Error: foo()() is not an lvalue
wut?
I think you need to write:
auto a = foo!();
Bye,
bearophile
On 04/17/2013 06:02 PM, bearophile wrote:
Ellery Newcomer:
dmd from master (a few days ago) gives:
Error: foo()() is not an lvalue
wut?
I think you need to write:
auto a = foo!();
Bye,
bearophile
wouldn't that be infinitely recursing template instantiation?
And that prevents a workaround for the missing auto ref. :o)
It seems dmd 2.060 is far more useable than 2.061 (for users
which use structs, of course).
I will switch back.
I'm still interested in this problem. But how can I identify the
specific compiler code where this error comes from?
I
On Monday, January 28, 2013 11:16:26 Namespace wrote:
And that prevents a workaround for the missing auto ref. :o)
It seems dmd 2.060 is far more useable than 2.061 (for users
which use structs, of course).
I will switch back.
I'm still interested in this problem. But how can I identify
It's fixed already. But I searched at the wrong place. The
compiler is too huge for me. o.O
The following code prints:
/home/c494/c719.d(27): Error: (Vec2!(float) __ctmp1173 =
_D4c71911__T4Vec2TfZ4Vec26__initZ;
, __ctmp1173).this(4F, 2F) is not an lvalue
[code]
import std.stdio;
struct Vec2(T) {
public:
T x;
T y;
this(T x, T y
Looks like a bug in function overload selection.
On Sunday, 27 January 2013 at 11:42:29 UTC, Dicebot wrote:
Looks like a bug in function overload selection.
I hope not!
That would be really bad. That is part of my solution as long as
auto ref isn't there. :D
Same with this code: http://dpaste.1azy.net/2c98fe95
But there I found no workaround.
This works: new C(cast(A) new B(), FloatRect(0, 1, 2, 3));
But that is ugly. o.O
I think you are right and it is a bug in function overload
selection. :(
Ok, I will open a bug report for this.
On Sunday, January 27, 2013 12:42:28 Dicebot wrote:
Looks like a bug in function overload selection.
Definitely.
- Jonathan M Davis
On Sunday, 27 January 2013 at 23:05:16 UTC, Jonathan M Davis
wrote:
On Sunday, January 27, 2013 12:42:28 Dicebot wrote:
Looks like a bug in function overload selection.
Definitely.
- Jonathan M Davis
And that prevents a workaround for the missing auto ref. :o)
It seems dmd 2.060 is far
If I don't comment out line 19 I get:
/home/c803/c821.d(19): Error: function c821.foo (ref A a) is not
callable using argument types (B)
/home/c803/c821.d(19): Error: cast(A)b is not an lvalue
Code: http://dpaste.dzfl.pl/89f55c62
Should not work all three?
On 12/26/2012 07:37 AM, Namespace wrote:
If I don't comment out line 19 I get:
/home/c803/c821.d(19): Error: function c821.foo (ref A a) is not
callable using argument types (B)
/home/c803/c821.d(19): Error: cast(A)b is not an lvalue
Code: http://dpaste.dzfl.pl/89f55c62
Should not work
I can answer the question in the subject line without looking
at dpaste: Yes, in many cases the result of a cast operation is
an rvalue. It is a temporary that is constructed at the spot
for that cast operation.
Imagine casting an int to a double. The four bytes of the int
is nowhere close
On 12/26/2012 09:05 AM, Namespace wrote:
I can answer the question in the subject line without looking at
dpaste: Yes, in many cases the result of a cast operation is an
rvalue. It is a temporary that is constructed at the spot for that
cast operation.
Imagine casting an int to a double. The
On Wednesday, 26 December 2012 at 17:13:14 UTC, Ali Çehreli wrote:
On 12/26/2012 09:05 AM, Namespace wrote:
I can answer the question in the subject line without looking
at
dpaste: Yes, in many cases the result of a cast operation is
an
rvalue. It is a temporary that is constructed at the spot
On Wednesday, 26 December 2012 at 19:45:53 UTC, monarch_dodra
wrote:
On Wednesday, 26 December 2012 at 17:13:14 UTC, Ali Çehreli
wrote:
On 12/26/2012 09:05 AM, Namespace wrote:
I can answer the question in the subject line without
looking at
dpaste: Yes, in many cases the result of a cast
On Wednesday, 26 December 2012 at 17:13:14 UTC, Ali Çehreli wrote:
Here is the code:
import std.stdio;
static if (!is(typeof(writeln)))
alias writefln writeln;
What does this for? I constantly face in code samples shared in
this NG.
On Wednesday, 26 December 2012 at 19:52:21 UTC, Maxim Fomin wrote:
On Wednesday, 26 December 2012 at 17:13:14 UTC, Ali Çehreli
wrote:
Here is the code:
import std.stdio;
static if (!is(typeof(writeln)))
alias writefln writeln;
What does this for? I constantly face in code samples
On 12/26/12, Maxim Fomin ma...@maxim-fomin.ru wrote:
static if (!is(typeof(writeln)))
alias writefln writeln;
What does this for? I constantly face in code samples shared in
this NG.
Probably for D1 compatibility. D1 didn't have writeln.
On 2012-10-31 23:48, Adam D. Ruppe wrote:
I tried it and found getting almost there is easy... but getting it
to work in a bunch of edge cases is incredibly difficult.
I can imagine operator overloading, opDispatch and similar features
making it a lot harder.
--
/Jacob Carlborg
maarten van damme:
Is there a rationale behind this decision of not translating
test.value+=1 to test.value= test.value +1 ?
I think it's a temporary limit, meant to be removed/fixed.
Bye,
bearophile
Ok, looking forward to the fix :)
Btw, I have a foreach loop and in that foreach loop I want to decide
if the current element can stay and if not, I want to remove it. If
removing it yields an empty range in the foreach loop, it crashes.
What's the sane way to do this?
On Wed, 31 Oct 2012 14:08:18 -, maarten van damme
maartenvd1...@gmail.com wrote:
Ok, looking forward to the fix :)
Btw, I have a foreach loop and in that foreach loop I want to decide
if the current element can stay and if not, I want to remove it. If
removing it yields an empty range in
: test.value() is not an lvalue
Is there a rationale behind this decision of not translating
test.value+=1 to test.value= test.value +1 ?
I think we need implement property rewrite to properly handle this.
--
/Jacob Carlborg
:
test.d(4): Error: test.value() is not an lvalue
You can make int value() to return by reference.
On Wednesday, 31 October 2012 at 12:46:12 UTC, maarten van damme
wrote:
Is there a rationale behind this decision of not translating
test.value+=1 to test.value= test.value +1 ?
Probably there were no such decision at all and you just ran into
issue which has never worked. BTW properties are
:
test.d(4): Error: test.value() is not an lvalue
Is there a rationale behind this decision of not translating
test.value+=1 to test.value= test.value +1 ?
It's not that simple as test.value is not an LValue, so from
the compiler's perspective test.value = test.value + 1 calls
two different
;
}
}
}
but this gives the following error:
test.d(4): Error: test.value() is not an lvalue
Is there a rationale behind this decision of not translating
test.value+=1 to test.value= test.value +1 ?
It's not that simple as test.value is not an LValue, so from the
compiler's perspective test.value
but this gives the following error:
test.d(4): Error: test.value() is not an lvalue
Is there a rationale behind this decision of not translating
test.value+=1 to test.value= test.value +1 ?
http://forum.dlang.org/thread/xcbweciovapinaicx...@forum.dlang.org
and
http://d.puremagic.com/issues
On 10/31/12, Michael p...@m1xa.com wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=8006
I wonder if this is low-hanging fruit to implement in the DMD
frontend. Could we really just implement var.property += 5; to
var.property = var.property + 5; or is it much more complicated than
that..
I
On Wednesday, 31 October 2012 at 22:46:17 UTC, Andrej Mitrovic
wrote:
I wonder if this is low-hanging fruit to implement in the DMD
frontend.
I tried it and found getting almost there is easy... but getting
it
to work in a bunch of edge cases is incredibly difficult.
1 - 100 of 133 matches
Mail list logo
