val x = p0.x * u * u * u * u
+4f * p1.x * u * u * u * t
+6f * p2.x * u * u * t * t
+4f * p3.x * u * t * t * t
+p4.x * t * t * t * t
logd("$x")
logd("${p0.x * u * u * u * u
+ 4f * p1.x * u * u * u * t
+ 6f * p2.x * u * u * t * t
+ 4f * p3.x * u * t * t * t
+ p4.x * t * t * t * t}")
Why the “x” value doesn’t equals the express’s value
D/Bezier (24518): 0.0 => this is x’s value
D/Bezier (24518): 347.0 => this is express’s value
I made the same mistake as flyliufu.
I think that such a description should be a compile error (at least a warning).
Even though the following description is grammatically valid, it is semantically invalid.
“+ 4f * p1.x * u * u * u * t”
If the above description is a compile error, the following description also causes a compile error.
list.add(element)
As for this problem, I think that it can be avoided by annotating the add () method to indicate that the return value is optional.
This is an unfortunate consequence of the fact that Kotlin does not require "; " separators for statements. Maybe unaryPlus could be special cased, but unaryMinus is a valid operator. The fact that expressions are valid statements interacts with this as well (also a desirable language design choice). As the expression could very well have side effects there is no valid way for any static analysis system to be certain what the valid code is.
This is an unfortunate consequence of the fact that Kotlin does not require “;” separators for statements.
I agree.
For programmers who are familiar with C and Java have to be aware that line breaks are different from blank characters.
As an answer to flyliufu, I noticed that there is also “enclose the entire right-hand side with parentheses”.
(The code with operators written at the end of the line seems a little strange to me.)
I can’t imagine why would anyone write “+1” or “-1” as a separate statement. It should be a warning, if making it an error is too late. I remember that some library used operator overloading for unary “+” for some strange thing, but it’s a clear demonstration that abusing operator overloading is a bad idea.