[Issue 3008] Members of non-lvalues (rvalues) can be assigned to.

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=3008





--- Comment #5 from Chad Joan <chadjoan at gmail.com>  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 _global;
> 
> struct S
> {
>   int _x;
>   version(noop)
>     void x(int n) { _x = n;}
>   else
>     void x(int n) { _global = n;}
> }
> 
> struct S2
> {
>   S foo() { return S(5);}
> }
> 
> void main()
> {
>   S2 s2;
>   s2.foo.x = 5;
> }
> 
> How does the compiler know when compiling with noop that the s2.foo.x = 5
> doesn't do anything?  Especially if the module containing main is using a di
> file to define S and S2.
> 
> The result is, I don't think the compiler can diganose the complex cases, and
> most of the time, the cases are complex.

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
get compiled.  Period.  When "s2.foo.x = 5;" is being analysed, the compiler
will walk the syntax tree for "void x(int n) { _x = n;}" and discover that
s2.foo is an rvalue.  This is what it already does, minus the "discover that
s2.foo is an rvalue" part.  

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 meat of the
matter.  In this example, "s2.foo.x = 5;" does actually do something and is
reasonable code.  However, naively forbidding an rvalue on the lhs of an assign
expression will make that code fail to compile.  I don't feel that code like
this is terribly common or that much better than the alternatives, so it is
probably worth losing some corner cases like these for the sake of preventing
nasty bugs.  

.di files change absolutely nothing.  They are .d files that just happen to be
mostly definitions because dmd generated that way.  There is nothing in the
spec saying that they even need to exist.  More importantly, Walter was
intentional about omitting them from the spec.

"D interface files bear some analogous similarities to C++ header files. But
they are not required in the way that C++ header files are, and they are not
part of the D language. They are a feature of the compiler, and serve only as
an optimization of the build process."
http://www.digitalmars.com/d/2.0/dmd-linux.html#interface_files

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------