It results in a Expected expression statement compile error.
mikeMon 27 Aug 2012
Casting in Fantom is done with the as keyword:
foo as Bar
But your example still won't compile even with as:
class Foo
{
Void main()
{
Obj i := 0
// won't compile
//(i as Int)++
z := (i as Int)
z++
echo("i: $i")
echo("z: $z")
}
}
But this does not increment i
brianMon 27 Aug 2012
Promoted to ticket #2012 and assigned to brian
That is just the compiler complaining that it thinks the increment is a no-op and an expression that doesn't map to a complete statement (because the increment is mixed in the with the cast). I think it just a tweak to the compiler that needs to a cast expression to pass thru in the check for Expr.isStmt.
Its actually a simple patch if someones to try their hand at making a compiler fix (with a test case!)
mikeMon 27 Aug 2012
I actually didn't know that java-style casts worked in Fantom, I though you had to use as. I like as a lot better.
Anyway, I'll take a stab at this fix unless Jens wants to.
JensMon 27 Aug 2012
Hm. Trying to use the increment method instead, which ++ is supposed to be a short cut for, I notice that it doesn't actually increment the receiver, but return the new value:
Void test()
{
Int i1 := 0
Int i2 := i1.increment
echo( "i1: " + i1 ) // Prints "i1: 0"
echo( "i2: " + i2 ) // Prints "i2: 1"
}
This also seems to be a bug?
Also, the documentation for sys::Int.increment does not specify if it should return the value of the receiver before or after the increment.
JensMon 27 Aug 2012
Anyway, I'll take a stab at this fix unless Jens wants to.
I had a quick look. The code in isStmt seems fine. And the error is coming from the parser, in exprOrLocalDefStmt.
(In the case when isStmt fails in the CheckErrors phase, Not a statement is reported instead)
It seems like it thinks that the whole statement ends with the cast, failing to associate ++ with the same statement. So it reports the cast with Expected expression statement.
I find the parser a bit tricky to understand...
SlimerDudeTue 28 Aug 2012
I notice that it doesn't actually increment the receiver, but return the new value:
Int, the receiver is a const type (same as all the Num types), so its value will never change - it has to return the new value.
JensTue 28 Aug 2012
Int, the receiver is a const type
Ah, of course, I see, thanks. It's a bit confusing with Ints double nature, value/const object.
brianMon 15 Oct 2012
Ticket cancelled
After looking at this a bit more, I'm thinking that it might be best to leave this a compiler error. The ++/-- operators a bit complicated in how they work on the runtime stack, and having a cast in there actually creates a lot of complication in the fcode b/w JVM and CLR runtimes.
JensTue 30 Oct 2012
It sure is a rather uncommon thing to do.
But it might be a good idea to have a better error message for it. Otherwise there might be a new bug-report on it some day.
Jens Mon 27 Aug 2012
Is this supposed to work?
It results in a
Expected expression statement
compile error.mike Mon 27 Aug 2012
Casting in Fantom is done with the
as
keyword:But your example still won't compile even with
as
:But this does not increment
i
brian Mon 27 Aug 2012
Promoted to ticket #2012 and assigned to brian
That is just the compiler complaining that it thinks the increment is a no-op and an expression that doesn't map to a complete statement (because the increment is mixed in the with the cast). I think it just a tweak to the compiler that needs to a cast expression to pass thru in the check for
Expr.isStmt
.Its actually a simple patch if someones to try their hand at making a compiler fix (with a test case!)
mike Mon 27 Aug 2012
I actually didn't know that java-style casts worked in Fantom, I though you had to use
as
. I likeas
a lot better.Anyway, I'll take a stab at this fix unless Jens wants to.
Jens Mon 27 Aug 2012
Hm. Trying to use the
increment
method instead, which++
is supposed to be a short cut for, I notice that it doesn't actually increment the receiver, but return the new value:This also seems to be a bug?
Also, the documentation for
sys::Int.increment
does not specify if it should return the value of the receiver before or after the increment.Jens Mon 27 Aug 2012
I had a quick look. The code in
isStmt
seems fine. And the error is coming from the parser, inexprOrLocalDefStmt
.(In the case when
isStmt
fails in the CheckErrors phase,Not a statement
is reported instead)It seems like it thinks that the whole statement ends with the cast, failing to associate
++
with the same statement. So it reports the cast withExpected expression statement
.I find the parser a bit tricky to understand...
SlimerDude Tue 28 Aug 2012
Int
, the receiver is a const type (same as all the Num types), so its value will never change - it has to return the new value.Jens Tue 28 Aug 2012
Ah, of course, I see, thanks. It's a bit confusing with
Int
s double nature, value/const object.brian Mon 15 Oct 2012
Ticket cancelled
After looking at this a bit more, I'm thinking that it might be best to leave this a compiler error. The ++/-- operators a bit complicated in how they work on the runtime stack, and having a cast in there actually creates a lot of complication in the fcode b/w JVM and CLR runtimes.
Jens Tue 30 Oct 2012
It sure is a rather uncommon thing to do.
But it might be a good idea to have a better error message for it. Otherwise there might be a new bug-report on it some day.