I agree it does not remove the need for casts.
Once you use the smallest type that fits for a generic literal, sin(1) is obvious. It is very easy to explain. Please remember that the smallest type that fits is a rule of last resort and it is imperfect for extreme/strange cases. The type of a literal should use context if that context exists. I will note that mathematically, the literal sin(1) has infinite precision and is unable to be evaluated on current hardware so I would regard it as an error in my own code. Only sin(1:uint(w)) for some w has finite precision.
I cannot explain why adding 42 to a 32-bit integer suddenly delivers a 64-bit integer without saying that Chapel has no such thing as a true literal.
The digit 1 is a literal. The typed value 1:int(64) is an anonymous param.
And yes, it is a breaking change but it is already broken for anybody trying to port existing code. Although it is not a breaking change if you have a compiler options like
--[no]default-literal-size
where ``--default-literal-size` is the default.
I would argue that Chapel is already broken because the expressions
param t = .<some 32-bit literal>
const s = <some 32-bit literal where t == s>
....
param x = t + 42;
const y = s + 42;
do not deliver the same overall result even thought == s. Overall result means more than just the numeric value. How do I explain that to novice programmers?
Getting back to readability:
param x = t + 42:t.type
is still ugly. I still cannot see why adding 42 to a 32-bit integer should deliver anything other than a 32-bit integer. In the expression
t + 42
The only type-related information provided by the programmer is the type of x so the compiler should not presume anything else.
I am not a big fan of any Chapel code that uses a declaration with a naked int or real.
I apologize for raising something that means work. But the Chapel concept of default sizes for those types and the handling of literals is going to cause more grief for int(128) and real(128) so I would argue that the issue needs to be addressed rather than later irrespective of the grief it is already causing me and others in porting existing code.
The concept of smallest type that fits is not mine.
P.S. If an integer literal has type int(256), i.e. beyond supported sizes, when it comes to using them in contextual expressions with objects of type int(w), you use a precedence of w % 256 for everything and then rely on the rules to promote the literal as appropriate. Then again, I have not worked on serious compiler internals for 24 years so I could be wrong.
Thanks again for your time Michael.