Robert Jacques wrote:
On Tue, 07 Jul 2009 21:21:47 -0400, Andrei Alexandrescu
<[email protected]> wrote:
Robert Jacques wrote:
On Tue, 07 Jul 2009 20:48:50 -0400, Andrei Alexandrescu
<[email protected]> wrote:
Robert Jacques wrote:
long g;
g = e + f; => d = cast(long) e + cast(long) f;
Works today.
Wrong. I just tested this and what happens today is:
g = cast(long)(e+f);
And this is (I think) correct behavior according to the new rules
and not a bug. In the new rules int is special, in this suggestion,
it's not.
I think this is a good idea that would improve things. I think,
however, it would be troublesome to implement because expressions
are typed bottom-up. The need here is to "teleport" type information
from the assignment node to the addition node, which is downwards.
And I'm not sure how this would generalize to other operators beyond
"=".
Andrei
Hmm... why can't multiple expressions be built simultaneously and
then the best chosen once the assignment/function call/etc is
reached? This would also have the benifet of paving the way for
polysemous values & expressions.
Anything can be done... in infinite time with infinite resources. :o)
Andrei
:) Well, weren't polysemous expressions already in the pipeline somewhere?
I'm afraid they didn't get wings. We have incidentally found different
ways to address the issues they were supposed to address.
Andrei
