https://issues.dlang.org/show_bug.cgi?id=3008
Iain Buclaw changed:
What|Removed |Added
Priority|P2 |P3
--
http://d.puremagic.com/issues/show_bug.cgi?id=3008
Jarrett Billingsley changed:
What|Removed |Added
CC||jarrett.billings...@gmail.c
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #4 from Steven Schveighoffer 2009-07-29
10:11:26 PDT ---
(In reply to comment #3)
> Actually the compiler wouldn't have to do anything special here. If the
> return
> of foo() were an rvalue, then *foo().a could still be an lv
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #5 from Chad Joan 2009-07-30 01:50:28 PDT ---
(In reply to comment #4)
>
> I think you are right that it can be determined in simple cases, but for sure
> there will be cases that the compiler cannot diagnose, such as:
>
> int
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #6 from Chad Joan 2009-07-30 02:09:09 PDT ---
On the newsgroup KennyTM~ pointed out that opDot() also suffers from this
problem:
struct S {
int s;
}
class X {
S opDot() { S temp; temp.s = 6; return temp; }
}
X z = new X;
a
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #7 from Steven Schveighoffer 2009-07-30
07:19:24 PDT ---
(In reply to comment #5)
> Of course, s2.foo().x(5) violates the principle at play here. At this point,
> the whole "version(noop)" thing is just fluff, and here is the
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #8 from BCS 2009-07-30 09:23:10 PDT
---
(In reply to comment #5)
>
> It's easy for the compiler to know that "s2.foo.x = 5" does nothing. When
> compiling with noop, the "void x(int n) { _global = n;}" version just does not
>
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #9 from Chad Joan 2009-07-30 10:38:44 PDT ---
(In reply to comment #7)
> (In reply to comment #5)
>
> > Of course, s2.foo().x(5) violates the principle at play here. At this
> > point,
> > the whole "version(noop)" thing is ju
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #10 from Chad Joan 2009-07-30 10:46:27 PDT ---
(In reply to comment #8)
> (In reply to comment #5)
> >
> > It's easy for the compiler to know that "s2.foo.x = 5" does nothing. When
> > compiling with noop, the "void x(int n) {
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #11 from BCS 2009-07-30 10:59:32 PDT
---
(In reply to comment #10)
> (In reply to comment #8)
> >
> > This assumes that the body of x is available for analysis and is simple
> > enough to be analysed.
>
> Oh my, I made it s
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #12 from Steven Schveighoffer 2009-07-30
11:12:25 PDT ---
(In reply to comment #9)
> You make it sound like we wouldn't be able to use structs anymore!
>
> Not the case.
What I mean is this:
original:
class C
{
void foo(
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #13 from Chad Joan 2009-07-30 12:46:33 PDT ---
(In reply to comment #11)
>
> OK then that's another (potentially worse) problem because I can think of
> several cases where I want to return a struct (by value) and invoke functio
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #14 from BCS 2009-07-30 13:02:20 PDT
---
(In reply to comment #13)
> That'd be a start.
>
> The problem then is that variable assignment is equivalent to function calls
> with 1 parameter due to the omitable parentheses rule.
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #15 from Chad Joan 2009-07-30 13:10:29 PDT ---
(In reply to comment #12)
> (In reply to comment #9)
> > You make it sound like we wouldn't be able to use structs anymore!
> >
> > Not the case.
>
> What I mean is this:
>
> or
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #16 from Chad Joan 2009-07-30 13:13:40 PDT ---
(In reply to comment #14)
>
> See above. Without analyzing the function bodies, Applying all this to
> functions will also ban things I'm not willing to give up.
>
> As an example:
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #17 from BCS 2009-07-30 13:26:32 PDT
---
(In reply to comment #16)
> (In reply to comment #14)
> >
> > See above. Without analyzing the function bodies, Applying all this to
> > functions will also ban things I'm not willing t
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #18 from Steven Schveighoffer 2009-07-30
13:40:56 PDT ---
(In reply to comment #15)
> Incorrect.
>
> s is an lvalue (it isn't being returned)
> s.getValue is an lvalue (pointer to some C's data, AKA a reference type)
*struct*
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #19 from Chad Joan 2009-07-30 14:00:29 PDT ---
(In reply to comment #17)
>
> You assume that the above is a bug and what I really wanted was to return a
> reference. Take another look while assuming that I actual do want return
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #20 from Chad Joan 2009-07-30 14:16:00 PDT ---
(In reply to comment #18)
> (In reply to comment #15)
> > Incorrect.
> >
> > s is an lvalue (it isn't being returned)
> > s.getValue is an lvalue (pointer to some C's data, AKA a re
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #21 from BCS 2009-07-30 14:35:05 PDT
---
(In reply to comment #19)
> (In reply to comment #17)
> >
> > You assume that the above is a bug and what I really wanted was to return a
> > reference. Take another look while assuming
http://d.puremagic.com/issues/show_bug.cgi?id=3008
--- Comment #22 from Steven Schveighoffer 2009-07-31
06:11:34 PDT ---
(In reply to comment #20)
> (In reply to comment #18)
> > > It's not going away because MyNiftyPointerTo!(C).getValue is an lvalue.
> >
> > MyNiftyPointerTo!(C) does not
https://issues.dlang.org/show_bug.cgi?id=3008
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #23 from Razv
22 matches
Mail list logo
