[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 #10 from Chad Joan <chadjoan at gmail.com>  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) { _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.
> 
> This assumes that the body of x is available for analysis and is simple enough
> to be analysed. 
> 
> The first will not be true of any C function, any function that calls a C
> function (etc.), any closed source lib or any function that calls into a closed
> source lib (etc.). 
> 
> The second will not be true in general because it can devolve into the halting
> problem. 
> 
> To keep things consistent, the rules used have to be defined in the spec,
> practicely ruling out powerful heuristics and computation logic systems, and
> have to act the same regardless of accessability to source, strongly ruling out
> anything that uses inter-procedural analysis (Walter has several times stated
> that semantic rules that require analysis of non local code are not going to
> happen).
> 

Oh my, I made it sound like the body of the thing would be analysed.  Poor
wording.

No that's not the case, I was mostly just referring to the declaration.  

The only thing that matters there is that it looks at foo's return type, finds
an rvalue, and thinks "hmmm, that might mess up someone's day."

My point was that it doesn't matter whether it looks at the noop version or the
non-noop version, either way it finds the same rvalue in the return and decides
to the negative.

> > .di files change absolutely nothing.
> 
> Technically, yes. .di files don't actually /add/ any problems here because the
> problems at issue can be caused by a .d file as well.
> 
> > 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.
> 
> Any implementation that doesn't give the same functionality as .di files
> (no-source symbol decelerations) effectively eliminates the ability to have
> closed source D libraries. Therefor, the feature causing problems effectively
> is part of the spec.

.di files and bodyless function declarations, these are two different things. 
While I'm at a loss to find bodyless function declarations defined anywhere in
the spec, they do seem to be /used/ in the spec:
http://www.digitalmars.com/d/2.0/function.html#parameters

Of course, I was not by any means doing a thorough search.  I only checked the
obvious tabs "Functions" and "Declarations".  (The spec seems hard to search :/
... needs more targeted search feature and liberal application of metadata.)

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