You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The --infer flag specified at the command line of lpython would infer the type of the variable from the RHS, thus allowing not to declare variable types in most cases. The return type of a function can be inferred from the "return" statements. The arguments of functions would still need to be typed, but later as we implement generics, say with syntax something like:
T=TypeVar("T")
deff(a: T, b: T):
c=a+breturncprint(f(3, 4)) # would instantiate f as f(i32, i32) -> i32print(f(3.5, 4.5)) # would instantiate f as f(f64, f64) -> f64
which with --infer would automatically infer the return type of "f" as T (as well as the type of c as T) and then the instantiation of the generics would correctly create full types at compile time.
Then we could go further, and --infer could simply make the following equivalent to the above:
deff(a, b):
c=a+breturncprint(f(3, 4)) # would instantiate f as f(i32, i32) -> i32print(f(3.5, 4.5)) # would instantiate f as f(f64, f64) -> f64
One tricky part is taht f(a, b) would technically be f(a: T, b: U), and I am currently not sure how one would infer the type of c = a + b. But maybe there is a way.
Initially --infer should not be on by default. It should be an opt-in feature, and we should gain experience with it and see if this is useful and if it can be on by default, or if will make Python code not as readable (such as like overuse of auto in C++). This option might be helpful for interactive use.
The text was updated successfully, but these errors were encountered:
This would also be helpful while dealing with NumPy: #5 (comment)
In general, I think strict type checking is useful for a large codebase, as it is easier to find bugs, or rather I should say: one would encounter fewer bugs.
Suggestion: when a constructor appears on the right-hand side of a definition, it's pure noise to repeat the hard type on the left-hand side. This ONE CASE should be safe always.
The
--infer
flag specified at the command line oflpython
would infer the type of the variable from the RHS, thus allowing not to declare variable types in most cases. The return type of a function can be inferred from the "return" statements. The arguments of functions would still need to be typed, but later as we implement generics, say with syntax something like:which with
--infer
would automatically infer the return type of "f" asT
(as well as the type ofc
asT
) and then the instantiation of the generics would correctly create full types at compile time.Then we could go further, and
--infer
could simply make the following equivalent to the above:One tricky part is taht
f(a, b)
would technically bef(a: T, b: U)
, and I am currently not sure how one would infer the type ofc = a + b
. But maybe there is a way.Initially
--infer
should not be on by default. It should be an opt-in feature, and we should gain experience with it and see if this is useful and if it can be on by default, or if will make Python code not as readable (such as like overuse ofauto
in C++). This option might be helpful for interactive use.The text was updated successfully, but these errors were encountered: